589608 - Namoroka in 3.6 nightly UA string busts google jsapi

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Doug Halamay]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100822 Minefield/4.0b5pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100822 Minefield/4.0b5pre

After going to this page: http://forecast.weather.gov/MapClick.php?site=pqr&smap=1&textField1=44.557716&textField2=-123.325366 and then clicking any link (e.g., the "More Local Wx:" link under Current Conditions), and then going back to the original page, the forward functionality is disabled, and there is no record of the original page in the back/forward history.



Reproducible: Always

Steps to Reproduce:
1. Load URL
2. Click on any link on the page to navigate to a new page
3. Go back

Actual Results:  
Forward button is disabled (should not be) and the new page does not show up in the history drop down (although it does appear in the overall browser history).

Expected Results:  
Forward button should work, allowing you to go forward to the new page again.

This also is a bug in the latest 3.6.9pre nightly: Mozilla/5.0 (Windows; compatible; U; Windows NT 6.1; en-US; rv:1.9.2.9pre) Gecko/20100822 Namoroka/3.6.9pre

I have reproduced with a clean profile on both the 3.6.9pre branch and m-c trunk.

Could possibly be Windows only, as another user of the latest nightlies in the Mozillazine forums using a Mac noted that it works correctly for him.

If I'd take a guess, it looks to have something to do with loading of the Google Maps widget on the original page - just a stab in the dark, though.  I'll try to narrow down a regression range.

Comment 1

[Doug Halamay]

I went all the way back to Firefox 3.0 and this bug still exists, so I'd say it's not a recent regression.

Comment 2

[Doug Halamay]

After some further narrowing, the problem appears to be with the Google jsapi script that loads on that page.  When I block the script with AdBlock, the problem disappears (of course, so does the map widget).

The script is at http://www.google.com/jsapi

Unfortunately, the js in that script is fairly obfuscated at first glance, so I'm not sure what is causing the problem.

Comment 3

[Doug Halamay]

Another update.  After some more examination, if I change the general.useragent.extra.firefox pref in about:config from the default in the 3.6.9pre nightlies ("Namoroka/3.6.9pre") to something that includes the word "Firefox" and drops the text after the last subversion number (e.g., "Firefox/3.6.9"), the problem goes away.  Similar results for the 4.0b5pre nightlies as well, although I don't even have to drop the "pre" to make it work (changing to "Firefox/4.0b5pre" fixes the problem).

So, there must be some strange interaction between the browser detection code in the Google jsapi loader and the way pages are stored in history.  Given all this, I'm not sure where this bug should really be filed under...evangelism, bookmarks & history, JS?

Comment 4

[Doug Halamay]

(In reply to comment #3)

I was slightly mistaken in my last comment.  Leaving the "pre" has no effect in either the 3.6.9 branch or the m-c trunk.  As long as the code-name is changed to "Firefox", the problem goes away.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So what makes this not evangelism?

Comment 6

[Doug Halamay]

No longer seeing this due to the fix in bug 588874, so resolving.