Closed
Bug 633821
Opened 14 years ago
Closed 11 years ago
Scroll position is wrong with Hash(#) anchor links
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: alice0775, Unassigned)
References
()
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
Reporter | ||
Updated•14 years ago
|
OS: Windows 7 → Linux
Reporter | ||
Comment 1•14 years ago
|
||
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
Reporter | ||
Comment 2•14 years ago
|
||
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
Comment 3•14 years ago
|
||
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.
Comment 4•14 years ago
|
||
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?
Comment 5•14 years ago
|
||
Why was this nominated as blocking? I don't see an explanation accompanying it, and leaving drivers to guess isn't a great situation!
Comment 6•14 years ago
|
||
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....
Comment 7•14 years ago
|
||
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.)
Comment 8•14 years ago
|
||
Oh, I somehow thought this was a devmo page.... OK, I'll try that.
Updated•14 years ago
|
Keywords: qawanted,
testcase-wanted
Comment 9•14 years ago
|
||
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....
Comment 10•14 years ago
|
||
<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.
Comment 11•14 years ago
|
||
- for now, though alice's regression range indicates that she may know more than I do.
blocking2.0: ? → -
Reporter | ||
Comment 12•14 years ago
|
||
(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
Comment 13•14 years ago
|
||
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.
Comment 14•14 years ago
|
||
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
Reporter | ||
Comment 15•14 years ago
|
||
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.
Comment 16•14 years ago
|
||
/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.
Comment 17•14 years ago
|
||
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.
Comment 18•14 years ago
|
||
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
Comment 19•14 years ago
|
||
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
Comment 20•14 years ago
|
||
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.
Comment 21•13 years ago
|
||
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.
Comment 22•13 years ago
|
||
And now it doesn't, worked once perfectly through the STRs on comment 17. Now "5. Reload the page." is broken again =(
Comment 23•13 years ago
|
||
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.)
Comment 24•11 years ago
|
||
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
Comment 25•11 years ago
|
||
> 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.
Description
•