Closed
Bug 668213
Opened 13 years ago
Closed 4 years ago
External link to named anchor doesn't take you to anchor point on page
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jack.zelig, Unassigned)
References
()
Details
(Keywords: regression, Whiteboard: DUPEME)
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).
Comment 1•13 years ago
|
||
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
Comment 3•13 years ago
|
||
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?
Whiteboard: DUPEME
Comment 4•13 years ago
|
||
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.
Comment 5•13 years ago
|
||
In that case, sounds like a timing change plus the images-loading-changes-heights thing...
Comment 7•13 years ago
|
||
> "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.
Comment 8•13 years ago
|
||
> 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.
Comment 10•12 years ago
|
||
This works correctly in IE8, IE9, Chrom and Opera.
Comment 11•12 years ago
|
||
One of the bugs matching the summary: bug 633821.
Comment 13•12 years ago
|
||
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?
Comment 14•12 years ago
|
||
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.
Comment 15•12 years ago
|
||
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?
Comment 16•12 years ago
|
||
> Can that point be detected by the browser
Maybe, though it will fail in various cases when the page is in fact running script....
Comment 17•12 years ago
|
||
>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.
Comment 18•11 years ago
|
||
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
Comment 19•11 years ago
|
||
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
Updated•11 years ago
|
Keywords: testcase-wanted
Comment 20•11 years ago
|
||
Any good work arounds for this bug?
Comment 21•10 years ago
|
||
I used the following script placed after all other Javascript, I'm using jQuery smoothScroll so you might have to modify for your application, but the idea is there. Works like a champ at http://cafedethaireno.net/index.php#togo_menu $(document).ready(function(){ var h = window.location.hash; if (h) { var headerH = $('#navigationMenu').outerHeight(); $('html, body').stop().animate({ scrollTop : $(h).offset().top - headerH + "px" }, 1200, 'easeInOutExpo'); event.preventDefault(); } });
Comment 22•8 years ago
|
||
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.
Comment 23•8 years ago
|
||
Confirming this bug in both FF 47.0 and 47.0.1 on Windows 10
Comment 24•6 years ago
|
||
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.
Comment 25•4 years ago
|
||
This bug no longer appears to be an issue as of at least FF 74.0 on Windows 10
Comment 26•4 years ago
|
||
Yes, a lot of work was done, see
https://groups.google.com/forum/m/#!searchin/mozilla.dev.platform/scroll$20anchoring/mozilla.dev.platform/66jW_XKCZew
May also be fixed (random list): bug 668213, bug 60307
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•