Closed Bug 633821 Opened 13 years ago Closed 11 years ago

Scroll position is wrong with Hash(#) anchor links

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: alice0775, Unassigned)

References

(
URL
)

Details

(Keywords: regression) 

Build Identifier:
Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre ID:20110213030344

Scroll position is wrong with Hash(#) anchor links

Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile
2. Open ( http://support.mozilla.com/en-US/kb/unable%20to%20download%20or%20save%20files#w_change-file-type-settings )
3.

Actual Results:
 Scroll position is wrong

Expected Results:
 should jump to Change file type settings

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/38754465ffde
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090916 Minefield/3.7a1pre ID:20090916031148
Fails:
http://hg.mozilla.org/mozilla-central/rev/3079370d6597
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090917 Minefield/3.7a1pre ID:20090917030714
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=38754465ffde&tochange=3079370d6597
OS: Windows 7 → Linux
Regression window(TM nightly):
Works:
http://hg.mozilla.org/tracemonkey/rev/5639c3f2e85b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090903 Minefield/3.7a1pre ID:20090903033640
Fails:
http://hg.mozilla.org/tracemonkey/rev/66235f4c4eea
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090904 Minefield/3.7a1pre ID:20090904033603
Pushlog:
http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=5639c3f2e85b&tochange=66235f4c4eea
In local build
build from 842e6c09e35a :Fails
build from 6f6aeece5fe4 :Fails
build from 0e7d673ab750 :Fails
build from 5639c3f2e85b :Works

Suspected:
0e7d673ab750	Jeff Walden — Bug 514309 - Object.prototype.hasOwnProperty mishandles non-primitive property name. r=brendan
Assignee: nobody → general
Blocks: 514309
blocking2.0: --- → ?
Component: General → JavaScript Engine
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
So what I see as the page loads is that we scroll to the right place, and then scroll again to the wrong place.  At least in an opt build.
On the layout end, it looks like the scroll position is in fact not changing between the two scrolls, so it's the content that has changed.

I can confirm that this content change doesn't happen if I comment the scripts on the page out, and the fact that whether it changes depends on some TM changesets is ... worrisome.

Unfortunately, the scripts are minified gunk.  Eric, is it possible to get non-minified copies of those scipts?
Why was this nominated as blocking?  I don't see an explanation accompanying it, and leaving drivers to guess isn't a great situation!
It was nominated as blocking because we have an ES5-something change that causes bizarre behavior changes on a live website.  So presumably either the site was depending on something it should not have depended on, or the change in question is broken and will likely break other sites too.  The problem is we don't know which....
Thanks.  This seems like something to sort out after we've sorted out all the things we *know* are needed for shipping, so softblocker at worst.

(Eric doesn't manage sumo, but if you pop into #webdev or ask James Socol you can probably get whatever you need.)
Oh, I somehow thought this was a devmo page.... OK, I'll try that.
Wait.  I see the same behavior in 3.6 as I do on trunk.  So either I'm seeing something different from Alice0775 or this is not a regression....
<r1cky> bz: jsocol: my guess its the show for code
<r1cky> it hides sections of the document on page load
<r1cky> which will screw up your scroll position

And indeed, that would give the behavior I see over here.
- for now, though alice's regression range indicates that she may know more than I do.
blocking2.0: ? → -
(In reply to comment #9)
> Wait.  I see the same behavior in 3.6 as I do on trunk.  So either I'm seeing
> something different from Alice0775 or this is not a regression....

Umm, Today, I can reproduce the problem on the build before 2009/09/16.
I wonder this result.
No longer blocks: 514309
I believe this is Platform: All as I see it on Mozilla/5.0 (Windows NT 6.0; rv:2.2a1pre) Gecko/20110324 Firefox/4.2a1pre ID:20110324030442 as well.
Can't really tell what fixed this but http://support.mozilla.com/en-US/kb/unable%20to%20download%20or%20save%20files#w_change-file-type-settings WFM now on Mozilla/5.0 (Windows NT 6.0; rv:2.2a1pre) Gecko/20110410 Firefox/4.2a1pre ID:20110410030507
This still happens on
http://hg.mozilla.org/mozilla-central/rev/09b605eb3e0d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110411 Firefox/4.2a1pre ID:20110411030525

STR
1. Start Minefield with _new_ profile (no add-ons)
2. Open  http://support.mozilla.com/en-US/kb/unable%20to%20download%20or%20save%20files#w_change-file-type-settings
or http://support.mozilla.com/en-US/kb/How%20to%20set%20the%20home%20page#w_restore-the-default-home-page

Note: if using existing profile, you should clear cache & restart browser.
/socol(In reply to comment #10)
> <r1cky> bz: jsocol: my guess its the show for code
> <r1cky> it hides sections of the document on page load
> <r1cky> which will screw up your scroll position

The code that did this was changed in bug 638884, we now reset the scroll height to the location of the anchor after applying our content changes.

If this is really a browser bug, I'd strongly encourage someone to find a more minimal test case than SUMO. We actively mess with the content length, offset position of the elements, and window scroll position.
I think I am seeing this issue on MXR:

1. Load http://mxr.mozilla.org/mozilla-central/source/js/src/jsutil.h#237
2. You are scrolled so line 237 is at the top of the page, the anchor link worked correctly.
3. Scroll away so line 237 is no longer shown.
4. Press enter in the url bar.
5. Reload the page.
6. In both 4 and 5, we stay in the same position - we are not scrolled to the anchor link. This is a regression as both 4 and 5 used to scroll us to the right place.
http://support.mozilla.com/en-US/kb/unable%20to%20download%20or%20save%20files#w_change-file-type-settings now WFM on Mozilla/5.0 (Windows NT 6.0; rv:6.0a1) Gecko/20110506 Firefox/6.0a1 ID:20110506030557
What's described on comment 17 is still broken on Mozilla/5.0 (Windows NT 6.0; rv:6.0a1) Gecko/20110506 Firefox/6.0a1 ID:20110506030557
Is bug 632667 a duplicate?

On Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110607 Firefox/7.0a1 ID:20110607184357 step 4 in comment 17 now works, reloading still doesn't work as expected.
Everything described in comment 17 WFM on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0a1) Gecko/20110626 Firefox/7.0a1 ID:20110626030229

Still think bug 632667 is a duplicate of this.
And now it doesn't, worked once perfectly through the STRs on comment 17.
Now "5. Reload the page." is broken again =(
In comment 17, pressing Enter in the URL bar now works properly for me on latest Nightly. Reloading still doesn't however. (Pressing Enter after a reload does work.)
Blocks: 668213
Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0

No longer reproduces on latest Nightly (buildID: 20130808030205).
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: qawanted, testcase-wanted
Resolution: --- → WORKSFORME
> No longer reproduces on latest Nightly (buildID: 20130808030205).

confirming with
Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0
and the link in comment 17.

But it's reproducible for me elsewhere, see bug 668213 comment 18
You need to log in before you can comment on or make changes to this bug.