I'm glad that this task has been created. I have been two weeks on vacation, carrying my mobile device only and watching activity in ca.wiki in my volunteer capacity. The jumps from mobile Echo notifications to desktop Flow pages were the single most annoying thing in my Wikipedia browsing.

The fix should be simple?

Note, this is somewhat related to T72318
Changing http://git.wikimedia.org/blob/operations%2Fpuppet.git/3e6275024bcd42d38ab9aa22a369760a56e50332/templates%2Fvarnish%2Ftext-frontend.inc.vcl.erb#L26 could make both redirect to the mobile site without having to worry about the canonical url. I'll leave it up to you if you want to merge T72318 into this and solve it this way.

Moved from Wikimedia-Site-requests to SRE since that's in the puppet repository, not mediawiki-config

Yes, in the puppet repository but in the mediawiki module. Since it's config you might argue for it to be in mediawiki-config. In the past it was in a separate repository "apache-config" which somehow made more sense to me, since many redirects in there really have nothing to do with mediawiki itself.

I can't reproduce this now. Clicking notification about a flow topic leads me to the mobile version of Flow.

Is this still happening?

What is blocking this ticket?

I couldn't reproduce the specific problems in this bug, but it also shows several issues with Echo and mobile that are being fixed:

1. We need to refactor MobileFrontend's flyout to use the new ooui version of Echo. There's a WIP patch already, but it was blocked on making the notifications widget work once again with a "combined" view, which now has patchsets awaiting (https://gerrit.wikimedia.org/r/#/c/249031/)
2. We need to refactor and redo the Special:Notifications page in general, there's a task about that, to fix it for both desktop and mobile view (there's a separate task for that)

More to the point, I don't think this should be "blocked". Some aspects of this ticket are under development, and others need closer scrutiny and to see if they're still happening so they can be fixed. I remembered this ticket in ready for pickup (partially due to the fact that the 'combined' flyout was supposedly another ticket), not in "blocked."

I'm not sure why it was moved to the blocked column.

Yes, my understanding is we took it because although we thought the fix would touch mobile code (and maybe even Varnish) we planned on doing it.

As you said, #1 and #2 are different bugs.

If none of the three "bug" cases in the description can be reproduced, this should be closed.

This problem can be reproduced today:

1. Watch a Flow topic and get it updated so it generates notifications.

2. On mobile, click the Bell icon to get the "Notifications" window.

These notifications have this format:

<link>Topic</link>
UserX responded on Discussion page

3. Click the Topic link.

This link leads to a desktop page.

Meanwhile, the equivalent Topic in your watchlist points to the mobile version of the same topic.

In fact, the problem seems to be even simpler:

• Clicking the topic link leads to the desktop page.
• However, tapping on the rectangle of the notification leads... to the mobile page!

Maybe the fix is as simple as using the same instruction to link the rectangle (the div?) and the link to the topic?

It looks like there has been a regression? Now both clicking the topic link and the rectangle will lead to the desktop page. As far as I can see, the link to the mobile page has been lost. I wish I knew where to look in order to see whether a new patch has been merged and by whom, in order to ask whether doing the opposite (change the code to bring both links to the mobile page) is feasible.

Testing betalabs for the scenarios described in the ticket:

@Etonkovidova in case it's useful information it's worth noting that you should run these tests on different user agents.

When the absolute URL is used the user agent is important. When you visit the desktop url a redirect to the mobile site and mobile domain will only happen when you are on a recognised mobile browser (regardless of whether you are already on the mobile site).

thx @Jdlrobson - it's certainly requires more exhaustive testing. The table in my comment is from testing on mobile device (iPhone) and from Chrome mobile simulator on the desktop. I am going to add some test results from production.

Testing *production** for the scenarios described in the ticket:

Could T72318: Echo should generate canonical diff links be related to this?

removing the sre tag as im not sure there is an re action. but please re add and update if im mistaken