External link to named anchor doesn't take you to anchor point on page




8 years ago
6 months ago


(Reporter: jack.zelig, Unassigned)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: DUPEME, URL)



8 years ago
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

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

8 years ago
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

Comment 2

8 years ago
Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110629 Firefox/7.0a1
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?
Whiteboard: DUPEME

Comment 4

8 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.
In that case, sounds like a timing change plus the images-loading-changes-heights thing...

Comment 6

8 years ago
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.

Comment 9

8 years ago
Considering comments 7 and 8, can this bug be closed?

Comment 10

7 years ago
This works correctly in IE8, IE9, Chrom and Opera.

Comment 11

7 years ago
One of the bugs matching the summary: bug 633821.


7 years ago
Depends on: 633821


7 years ago
Duplicate of this bug: 773729

Comment 13

7 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?
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

7 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?
> 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

7 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

6 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
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).
Ever confirmed: true
Keywords: testcase-wanted

Comment 20

5 years ago
Any good work arounds for this bug?

Comment 21

5 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 

    var h = window.location.hash;
    if (h) {
        var headerH = $('#navigationMenu').outerHeight();
		$('html, body').stop().animate({
			scrollTop : $(h).offset().top - headerH + "px"
		}, 1200, 'easeInOutExpo');

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

3 years ago
Confirming this bug in both FF 47.0 and 47.0.1 on Windows 10

Comment 24

10 months 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.


6 months ago
See Also: → bug 1476049
You need to log in before you can comment on or make changes to this bug.