www.gotransit.com - see bug description

[armenzg]

URL: http://www.gotransit.com/timetables/en/schedules/full_schedules.aspx Browser / Version: Firefox Mobile 52.0 Operating System: Android 5.1.1 Problem type: Something else - I'll add details below

Steps to Reproduce

1. Navigate to: Site URL
2. Firefox settings button
3. Request desktop site

Expected Behavior: It switches to the desktop site

Actual Behavior: It still shows the mobile site

From webcompat.com with ❤️

[adamopenweb]

I can reproduce this issue on desktop by spoofing the Firefox Android user agent. The site will switch from desktop to mobile view, but reverting the user agent back to desktop Firefox, the site stays on the mobile view.

In Chrome for Android requesting desktop site works as expected.

[karlcow]

seeAlso: #2404 #3557 #3668

[MDTsai]

When I set to "Request desktop site", Firefox mobile request stylesheet and script only. Take site.css as example, user agent string is:

User-Agent:"Mozilla/5.0 (Android 5.0.2; Mobile; rv:53.0) Gecko/53.0 Firefox/53.0"

Even I manually reload, I can't get request using correct user agent string:

User-Agent:"Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0"

User agent doesn't change is weird, even LOAD_FLAGS_BYPASS_CACHE is set.

[denschub]

Oh, this turns out to be way more interesting than I thought.

The initial issue, that is, the site not switching between views is indeed a Fennec issue. The site comes packed with a Cache-Control: private, max-age=45 header, so we don't reload the html even if we hit reload. @MDTsai mention of a UA not changing is probably bug 1280583, but that's unrelated here, I guess. I filed 1349586 for invalidating the cache when requesting the desktop site. However, this is technically not a webcompat related issue, so I won't mark this as one.

However, there is another thing. While playing around with the site on Desktop, I sometimes managed to reload the site with no assets at all - CSS, JS and all images where missing. I somehow to managed to break the caching state and document.baseURI suddenly was wysiwyg://3/http://www.gotransit.com/timetables/en/schedules/google_trip_planner.aspx. Since all assets are prefixed with double slashes, for example //cdn.mobify.com/sites/mlx-gotransit/production/css/icons/icons.data.svg.css, this gets quite messy.

I yet have to find a way to reliably reproduce that. 🙈

[denschub]

Note that wysiwyg:// apparently is used to serve cached sites:

A channel to manage all cache-related interactions for layout when it is dealing with dynamic pages created through document.write(). This interface provides methods that will help layout save dynamic pages in cache for future retrievals.

Sounds funky, and I have no idea what that does!

[denschub]

JFTR, I am able to reproduce: open the site, open RDM with a mobile-y user agent (I'm using a Nexus 7 here) and force-reload to get the mobile view.

After that, when you force-reload and bypass the cache (by either shift-clicking the reload icon or hit cmd-shift-r), the site breaks and the baseURI contains wysiwyg://. If you do a normal reload instead (f5 or cmd-r), the site works as expected.

[karlcow]

Cache-Control: private, max-age=45 is telling that for the next 45 seconds the resource should be taken from the browser cache, without making a conditional request. You can only force reload if you do shift-reload (on desktop). I understand it creates issue for Request Desktop Site. I will follow-up on the bug. Thanks @denschub

There are indeed weird things happening at the first load:

Note the "Navigated to wyciwyg://0/http://www.gotransit.com/timetables/en/schedules/full_schedules.aspx"

This should not happened. I have the feeling that it is related to document.write

See this https://webcompat.com/issues/1267#issuecomment-119192751 And this for an explanation https://miketaylr.com/posts/2014/08/document-writing-zeptos.html

And mobify was the cause. They need to update the mobify version they are using.

[denschub]

That's interesting! Still, I think the broken baseURI is a Firefox bug. Have to build a small testcase for that and see if this is an actual issue or just a weird side-effect from mobify. Thanks for your knowledge, that saved a bunch of time!

[karlcow]

Given the previous analysis here, I would push this in needscontact. I guess @adamopenweb is in the best position for this.

[karlcow]

We had difficulties to contact them in the past. Quite unfortunate.

I wonder if @mmacaulay is related to the organization.

[adamopenweb]

They have a new site in beta that works fine in Fennec from my quick tests: https://beta.gotransit.com/

[mmacaulay]

Hi,

No, I am not related to Go Transit or Metrolinx. I have played around with their transit feed data a bit in the past, but that's it.

[adamopenweb]

I think we should close this report as this version of the website is being phased out.

Thanks everyone!