Description: If the user goes into the Youtube app, Selects the desktop option, Selects the mobile link at the top, closes and terminates the app, then opens the Youtube app again and the app will remain defaulted to the desktop site. Repro Steps: 1) Updated Buri to Build ID: 20140106004001 2) Download the Youtube app. 3) Select the Youtube app. 4) Select the option "Desktop" within the option menu. 5) Select the mobile Youtube link at the top of the page. 6) Close and terminate the app. 7) Select the Youtube app again. Actual: The app opens the Desktop Youtube site. Expected: The app opens the Mobile Youtube site which was last selected to default to. Environmental Variables Device: Buri v 1.3.0 COM RIL Build ID: 20140106004001 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/a43cb4b322d3 Gaia: 35a60b82f8cf2d759939a350e2dadbb9d8b2f5dc Platform Version: 28.0a2 RIL Version: 01.02.00.019.102 Notes: Repro frequency: 5/8 See attached: YoutubeDesktopLOG.txt The issue often happens 100% with a newly flashed phone.

This issue does not occur in Buri 1.2 or Buri 1.1 1.2 Environmental Variables: Device: Buri 1.2 MOZ BuildID: 20140108004002 Gaia: 539a25e1887b902b8b25038c547048e691bd97f6 Gecko: 0d8b879ffd70 Version: 26.0 Firmware Version: 20131115 1.1 Environmental Variables Device: Buri v 1.1.0 COM RIL Build ID: 20140102041202 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/bdac595a4e46 Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f Platform Version: 18.1 RIL Version: 01.01.00.019.281

I think this is expected behavior. What's happening here is that the user has changed their settings in the YouTube app to point to the desktop site, so that's what will render on load. There's probably a cookie being set allowing this to happen.

(In reply to Jason Smith [:jsmith] from comment #2) > I think this is expected behavior. What's happening here is that the user > has changed their settings in the YouTube app to point to the desktop site, > so that's what will render on load. There's probably a cookie being set > allowing this to happen. Actually, let's keep this open to find out why the behavior did change. Let's get a window to find out.

This issue occurs all the way back to the first working Buri 1.3 Build ID: 20130919040201 Gaia 0dedb5b3789afc638a0c7c67652937fcb30e77d2 SourceStamp 803189f35921 BuildID 20130919040201 Version 27.0a1 This does not reproduce on the Buri 1.2 9/16 which was the last 1.2 Master before the branch off to 1.3. Something must have changed, or broken between the branch off for this issue to occur because it was working before. It's definitely not a good user experience (obviously not a blocker) But, as a user when using the YouTube App, if I switch to Desktop view, then switch back to mobile, I should be in mobile view when I relaunch the app.

Hi Ben, Do we know if the user agent changed in 1.3? or 28?

(In reply to Preeti Raghunath(:Preeti) from comment #5) > Hi Ben, > > Do we know if the user agent changed in 1.3? or 28? I can answer this. The user agent changes every single gecko version we ship, but other than that, there shouldn't be anything different here. Karl - Do you know of why this bug could be occurring on Gecko 27+?

What is the exact HTTP user agent string sent by the 1.3 Buri build? What is the exact navigator.userAgent string sent by the 1.3 Buri build?

so on the command line by using User-Agent: Mozilla/5.0 (Mobile; ZTEOpen; rv:25.0) Gecko/25.0 Firefox/25.0 User-Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0 User-Agent: Mozilla/5.0 (Mobile; rv:28.0a2) Gecko/28.0a2 Firefox/28.0a2 I get always the same result: HTTP/1.1 302 Moved Temporarily Location: http://m.youtube.com/index?&desktop_uri=%2F BUT on spoofing on Firefox Desktop these UA The UA string with two digits redirects to (nicer mobile version) "Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0" http://m.youtube.com/home Cookies: PREF f1=50000000&fms2=10000&fms1=10000 GPS 1 VISITOR_INFO1_LIVE randomString YSC randomString The UA string with "a" inside stays at (basic mobile version) Mozilla/5.0 (Mobile; rv:28.0a2) Gecko/28.0a2 Firefox/28.0a2 http://m.youtube.com/index?&desktop_uri=%2F Cookies: PREF f1=50000000 GPS 1 VISITOR_INFO1_LIVE randomString YSC randomString if I artificially set the PREF Cookie to f1=50000000&fms2=10000&fms1=10000, I get the nicer mobile version by being redirected to http://m.youtube.com/home Note also that typing by hand http://m.youtube.com/home doesn't change the layout and it stays with http://m.youtube.com/index?&desktop_uri=%2F. So definitely the PREFS cookie has a strong influence on the final rendering. On the other hand if you type http://m.youtube.com/index?app=desktop You get a desktop site redirected to http://www.youtube.com/index?app=desktop and cookie has been changed to PREFS f1=50000000&fv=11.9.900 if you type http://www.youtube.com/index?app=mobile You get redirected to the mobile site * for UA with "a" to http://m.youtube.com/index?app=mobile&desktop_uri=%2Findex%3Fapp%3Dmobile * for normal UA Firefox OS string to http://m.youtube.com/home

So if I understand this bug correctly, this sounds like we're getting redirected to a desktop site only when "a" is present in the version of the UA. That problem will only happen on Nightly & Aurora builds, so this isn't a blocker. We should note this problem to YouTube, however.

Yes and no, but there is indeed, different type of behavior from the Web site related to a combination of URI, Cookies and User Agent format.

In Comment 1, 4) Select the option "Desktop" within the option menu. 5) Select the mobile Youtube link at the top of the page. 6) Close and terminate the app. This part must be creating a cookie for Desktop preferences. I would love to know if the test could be done with 1.3 and a "normal UA" string, and if the same behavior is happening. My hunch is that it doesn't happen and we could close it safely.

I can't reproduce it on OPENC. Can anyone else confirm it?

Unable to reproduce on Buri 1.3. Changing status to Resolved - Fixed.