User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110615151330 Steps to reproduce: Click on the following link (or enter it into the address bar) using FF4 or FF5 on PC http://www.rd.ruhr-uni-bochum.de/filme.html#neuro Actual results: I am taken to the bottom of the page Expected results: I should be taken to the anchor point on the page (in this case about half way down).
Reproduced: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110629 Firefox/7.0a1 If I click the link or paste it in the location bar I get to the bottom of the page. But! If I put the cursor at the end of the location bar once again and then press enter I get to the anchor point.
OS: Other → All
Version: 5 Branch → Trunk
Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110629 Firefox/7.0a1 confirming
Component: General → Document Navigation
Keywords: regression, testcase-wanted
Product: Firefox → Core
QA Contact: general → docshell
Looks like a duplicate of the general "changes in height/layout don't play well with named anchors" issue to me... This is labeled a regression. When did this work, exactly? What's the regression range?
Last good nightly: 2010-05-03 First bad nightly: 2010-05-04 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519 Setting html5.parser.enable false makes the bug disappear, thus it's likely http://hg.mozilla.org/mozilla-central/rev/358113b3642e that made it visible.
In that case, sounds like a timing change plus the images-loading-changes-heights thing...
Any news about this issue?
> "changes in height/layout don't play well with named anchors" I'm not sure this is something we're actively working to fix. It sounds like you'd have to do something like "If onload hasn't yet fired, you loaded a named anchor and haven't scrolled away, and the page's layout changes, scroll the viewport to the new anchor position." The website can fix this by laying its content out statically -- for instance, by specifying heights and widths on the images.
> I'm not sure this is something we're actively working to fix. dbaron has been thinking on and off about it for years. As you note, it's a hard problem.
Considering comments 7 and 8, can this bug be closed? Thanks
This works correctly in IE8, IE9, Chrom and Opera.
One of the bugs matching the summary: bug 633821.
The scroll works if you put the cursor in the address bar and press enter. Can't we have that action fire after the page has been loaded & laid out, automatically, instead of requiring that step of (highly unintuitive, hard-to-discover) manual interaction?
WBT, that action _already_ fires after the page has been loaded, if it hasn't happened yet. The problem with the particular page in this bug is that the scroll action happens, and then the page layout gets changed. It gets changed _after_ the page is loaded, in fact.
Bug 773729 Comment 0 has two Wikipedia talk page URLs, one that works and one that doesn't. I'm doing a lot of work with Wikipedia talk page named anchor URLs at the moment, and am finding some interesting behavior there (like https://en.wikipedia.org/w/index.php?title=Talk%3AAutism%2FArchive_9#Other_causes_in_the_lead which does not load to either the target or the bottom of the page, but another deterministic location). These are functionally static pages. The user experience is that the page loads once and does not change; even when new content is added to a discussion a reload is required to see that content. The non-highest-numbered archive pages pretty much never get new content and only change with Wikipedia's general stylesheet & chrome. There is a point very shortly after pageload when the layout is complete. That is the point when the workaround (click in address bar, press enter) becomes available (if you know about it) and necessary. Can that point be detected by the browser, which is loading the page and doing the layout, and doing the scrolling, and can the scroll-to-named-anchor action be triggered then?
> Can that point be detected by the browser Maybe, though it will fail in various cases when the page is in fact running script....
>though it will fail in various cases when the page is in fact running script.... As long as it fails gracefully, it'd be better to fail in some cases than in all (as is current behavior). Any scripts that are running onLoad should probably be allowed to return before this jump-to-anchor action is fired, and the action should be cancelled if the user has manually adjusted the page scroll position.
Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0 Bug 633821 (which I considered a duplicate) was closed as WFM today. But I can reproduce this one: - clear cache - go to URL ( http://www.rd.ruhr-uni-bochum.de/filme.html#neuro ) result: I'm on the bottom of the page
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:26.0) Gecko/20100101 Firefox/26.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0 I can reproduce this on Ubuntu 12.04 x32 and Mac OS X 10.8 but not on Windows 7 x64 nor Windows XP x32 with latest Nightly (buildID: 20130808030205).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Any good work arounds for this bug?
20160502172042 Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0 20160519030232 Mozilla/5.0 (Windows NT 6.1; rv:49.0) Gecko/20100101 Firefox/49.0 I have tested your issue on latest FF release 46.0.1, latest Nightly build 20160519030232 and managed to reproduce it.
Confirming this bug in both FF 47.0 and 47.0.1 on Windows 10
Confirming that this bug still exists in "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" Tested with URL: http://cs231n.github.io/neural-networks-case-study/#grad Seems to occur when a page has images or other content where the size of the item is not specified and the content has not been cached. The most likely cause is that the browser jumps to the correct anchor before all of the embedded content loads. When the embedded content loads, it shifts the text and any already loaded content down, meaning the page appears to jump up.
You need to log in before you can comment on or make changes to this bug.