mwalker wrote:

Fundraising's initial response is going to be just to just remove the filtering -- however, it would be a good feature for mobile frontend if that cookie was somewhat smarter (enough to remove itself when not needed / or track where it came from originally: varnish vs url click.)

Removing the filtering comes at the expense of potentially exposing users to banners that don't work particularly well on small screens.

Change 73999 had a related patch set uploaded by Mwalker:
(Bug 51465) No Longer Filtering Mobile Devices

https://gerrit.wikimedia.org/r/73999

Change 73999 merged by jenkins-bot:
(Bug 51465) No Longer Filtering Mobile Devices

https://gerrit.wikimedia.org/r/73999

Just to check I understand the problem correctly:
You want to show a banner on the desktop site (en.wikipedia.org and friends) when viewed in a mobile phone?
Was there any reason you didn't do this before? I don't really understand the logic... ResourceLoader disables JavaScript on older phones so these banners should work perfectly fine.

Could you clarify "Removing the filtering comes at the expense of potentially exposing users to banners that don't work particularly well on small screens." - if a mobile views the desktop site on their phone they will either use a modified viewport [1] and the banner will look exactly the same as desktop, or if there is no viewport the entire website will be unreadable so I'd be surprised they'd even be in desktop mode.

Does this effect the mobile site (en.m.wikipedia.org and friends) in anyway?

I'm also unclear how this effects the VisualEditor roll out... (you mention this in the CentralNotice fix).

The stopMobileRedirect cookie exists for a reason - if a user of the mobile site wants to see the desktop site this stops them from being redirected on every visit.

We could only set the stopMobileRedirect cookie if the user is on a mobile phone but this is messy and I don't see what value the work put in to achieve this would gain. Does anything really need to change in MobileFrontend now?

[1] http://www.quirksmode.org/mobile/viewports2.html

mwalker wrote:

(In reply to comment #4)

You want to show a banner on the desktop site (en.wikipedia.org and friends)
when viewed in a mobile phone?

Nope -- we want to show a banner on the desktop site to a desktop user who has previously used the mobile interface.

Could you clarify "Removing the filtering comes at the expense of potentially
exposing users to banners that don't work particularly well on small
screens."

With CentralNotice not filtering; true mobile users who choose to use the desktop site may be presented with a banner that doesn't work on small screens - e.g. the buttons are too small to hit with a finger.

Does this effect the mobile site (en.m.wikipedia.org and friends) in anyway?

No. Only the desktop site (and the transition of a desktop user between that and the mobile site and back.)

I'm also unclear how this effects the VisualEditor roll out... (you mention
this in the CentralNotice fix).

VE is only involved because we spotted it with a VE banner (they want to show to everyone so we're getting lots of interesting CN bugs.)

The stopMobileRedirect cookie exists for a reason - if a user of the mobile
site wants to see the desktop site this stops them from being redirected on
every visit.

Yep, understood. The feature request is more to not return 'desktop' devices to the desktop site after having viewed the mobile site with a stopMobileRedirect cookie.

We could only set the stopMobileRedirect cookie if the user is on a mobile
phone but this is messy and I don't see what value the work put in to achieve
this would gain. Does anything really need to change in MobileFrontend now?

Meh; don't know. This is an edge case... It's more related to if we have more things that are device dependent using the cookie to determine if someone is on a big device or not.

"With CentralNotice not filtering; true mobile users who choose to use the
desktop site may be presented with a banner that doesn't work on small screens

• e.g. the buttons are too small to hit with a finger."

This is a non-issue
The banner will be exactly the same size for users viewing the desktop site on a mobile device.

mwalker wrote:

Illustration of why desktop banners should not be served to mobile users

Adam got this whilst browsing on the desktop site on his phone whilst logged out.

Attached:

Is that zoomed in?
Does it disappear when you scroll?
Is it fixed position or absolute?

How can one access that banner on a phone - is there a url? Looks like with a few tweaks to the css that should be easy render correctly on a desktop view on a mobile screen...

I'm marking this as wontfix.

While I see your point about not setting the stopMobileRedirect cookie for devices that wouldn't normally get automatically redirected (eg a desktop browser), we don't have a reliable way to detect that, so without rearchitecting, we can't really achieve this. Ultimately, we've been attempting to simplify how MobileFrontend works - partly for performance/caching reasons and partly for codebase sanity, and I do not think this usecase is compelling enough to warrant additional complexity.

I suspect Jon is right that with some CSS magic you may be able to resolve the specific issues you're running into with the banners. Otherwise, we should have a bigger discussion about how best for you guys to achieve what you need from within CentralNotice.