657905 - Firefox 4 does not pass url parameters to the javascript function

Status: RESOLVED DUPLICATE of bug 647885

(Core :: General, defect)

Description

[carolyn.boschi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 ( .NET CLR 3.5.30729; .NET4.0E)

Our website navigation is controlled by a javascript function that receives a url parameter. The url parameter tells the javascript function which page to display and the coordinates it needs to slide the body background image into place.

The index.html page contains 3 divs (aka: pages). The proper "page" will slide into place when the link is clicked.

The links are structrued as follows:

<a href="index.html">page link 1</a>
<a href="index.html?whichPage=1">page link 2</a>
<a href="index.html?whichPage=2">page link 3</a>

This function works in every browser except Firefox 4 (including Firefox 3.6.xx, IE 6 through 8, Chrome 11.0.696.68 and Safari 5.0.5).

The error console does not throw any errors, the page validates using W3C validator.

Reproducible: Always

Steps to Reproduce:
1. user comes to our site
2. clicks on navigation link
3. 

Actual Results:  
If link is clicked for a "sub page" (for example: <a href="index.html?whichPage=1">page link 2</a>), nothing happens.

If a link is clicked for a "top level" page (for example: <a href="index.html">page link 1</a>) a user is usually brought to that page, but not always.

Expected Results:  
User clicks on navigation link, url parameter is passed to javascript function which displays appropriate div and slides body background image to correct coordinates.

Comment 1

[carolyn.boschi]

If a link is clicked for a sub page, for example: <a href="subpage.html?whichPage=2">page link 3</a>, 

the expected destination appears in the location bar:  http://www.oursite.com/subpage.html?whichPage=2, but the user is actually taken to the top level of that page:

http://www.oursite.com/subpage.html

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

Care to provide a Testsite and/or reduced Testcase (attached to this Report) showing the Issue?

Comment 3

[carolyn.boschi]

Here's the url to our site so you can see the issue:

http://www.sudlerdigital.com/clients/bi/combivent_website_2011/consumer/index.html

The issue is with the links in the left navigation (orange block).

Please let me know if you need anything else. Many thanks.

Comment 4

[Thomas Ahlblom]

Regression range:

Last good nightly: 2010-09-15 First bad nightly: 2010-09-16

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0caec4ddff74&tochange=f38ef1080bfe

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

Ok, I can provide a more reduced Window due to saved Hourly Builds:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0caec4ddff74&tochange=fa55e317302a

Comment 6

[Boris Zbarsky [:bzbarsky]]

This looks like fallout from bug 594934 based on a local bisect.  I wonder what this page is doing with background-position and why it fails....

Comment 7

[Boris Zbarsky [:bzbarsky]]

If I change the computed background-position result to output "0px 0px" instead of "0% 0%" when the offsets are both 0, the problem goes away.  So clearly _something_ here is looking at computed background-position and making assumptions about the values it'll get back.