810690 - After a search in Google and selecting "request desktop site" it reloads Google without the search

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[donrhummy]

User Agent: Mozilla/5.0 (Android; Tablet; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20121106195411

Steps to reproduce:

Did a search on Google images, then in Firefox's menu chose "request desktop site"


Actual results:

it loaded Google.com without my search.


Expected results:

it should have kept the search and converted it to a resist for the regular Google.com. this works properly in chrome.

I was using Firefox beta.

Comment 1

[Paul Feher]

I see the same behavior if I try to access an article on yahoo. After I select the "request desktop site"  the home page is loaded and the accessed article is lost. 

Aaron can we have you input here?

Comment 2

[Aaron Train [:aaronmt]]

More of a question for Brian. This is likely a limitation of the implementation of the feature.

Comment 3

[Brian Nicholson (:bnicholson)]

When a page is loaded, many sites first do redirects to show the mobile versions (i.e., going to http://www.yahoo.com automatically redirects to http://m.yahoo.com). When desktop mode is requested, we load the pre-redirect URL (http://www.yahoo.com) instead of the post-redirect URL (http://m.yahoo.com), which works in most cases.

If we don't have a redirection, though, we have a bit of a problem. Say go to http://m.yahoo.com/w/ygo-frontpage/lp/story/us/2837636/coke.bp in Fennec (or you can simply go to yahoo.com, then click an article as Paul described in comment 1). You then request desktop mode - what URL should be loaded? If we simply load the same URL with a desktop user agent, we'll still be at the mobile version of the page (you can test this easily by clicking the above link in your desktop browser).

To fix this, we aggressively strip most of the URL. First, we recognize that the "m" subdomain here is almost always an indicator that we're on a mobile site, so we remove it. In this example, that leaves us with http://yahoo.com/w/ygo-frontpage/lp/story/us/2837636/coke.bp. But in this case (and most cases), this leaves us with an invalid URL. So we also strip the entire path of the URL, leaving us with just http://yahoo.com.

If you try to load this same URL in Chrome or the stock browser, then choose Request Desktop Site, you'll still be on the same mobile page for the reasons stated in the second paragraph above. That's the tradeoff: you either end up with a non-desktop version of the same page (unless the site correctly handles switching between desktop and mobile versions of a page for a given URL), or you end up with a desktop version of the site's host URL. Unfortunately, most sites don't correctly switch between desktop/mobile versions of a page when the UA changes, so we went with the latter approach. The thinking was that if the user requests desktop mode, we should do everything we can to guarantee that we show a desktop version of the site.

Google is an exception in that it does correctly handle switching between desktop and mobile versions of a page for a given URL, so this is one case where our implementation backfires.

Comment 4

[Brian Nicholson (:bnicholson)]

In case you're interested, here's the code where we follow this behavior: http://hg.mozilla.org/integration/mozilla-inbound/file/094819a5ee7a/mobile/android/chrome/content/browser.js#l2617

Comment 5

[Aaron Train [:aaronmt]]

Is this bug actionable or wont-fix? If so, please mark as new.

Comment 6

[Brian Nicholson (:bnicholson)]

We're doing this intentionally, so I vote WONTFIX.