Last Comment Bug 645075 - html-5.com - Scrolling to anchor fails in Firefox 4 (works fine if javascript disabled)
: html-5.com - Scrolling to anchor fails in Firefox 4 (works fine if javascript...
Status: NEW
: regression
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 Windows 7
: -- major with 30 votes (vote)
: ---
Assigned To: Timothy Nikkel (:tnikkel)
:
:
Mentors:
http://www.HTML-5.com/examples/index....
: 666718 (view as bug list)
Depends on:
Blocks: 559996
  Show dependency treegraph
 
Reported: 2011-03-25 10:44 PDT by Rob Simpson
Modified: 2016-08-10 16:14 PDT (History)
26 users (show)
martijn.martijn: needinfo? (tnikkel)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
patch (29.35 KB, patch)
2011-04-13 21:59 PDT, Timothy Nikkel (:tnikkel)
jonas: review+
Details | Diff | Splinter Review
unbitrotted (25.83 KB, patch)
2012-11-08 11:36 PST, Timothy Nikkel (:tnikkel)
no flags Details | Diff | Splinter Review
scrollcontentsink.diff unbitrotted again (25.80 KB, patch)
2015-02-06 10:28 PST, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details | Diff | Splinter Review
scrollcontentsink_b.diff (27.30 KB, patch)
2015-02-06 14:10 PST, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details | Diff | Splinter Review

Description Rob Simpson 2011-03-25 10:44:16 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0

(Such a glaring bug, thought it should be reported already, but couldn't find one. Sorry if it's a duplicate.)

Firefox 4.0 does not automatically scroll down to location indicated by the fragment identifier in URL when user clicks on the link. If URL is re-entered in the address bar, then it scrolls as expected.

For example, click on any of the "... Examples" links on the web page at http://www.HTML-5.com/examples/index.html. Note the hash symbol and fragment identifier at the end of the URL. You would have expected it to scroll down to the element with id="examples", but it doesn't.  Now position the cursor at the end of the URL in the address bar, and without changing anything just hit Return. Now it scrolls down as expected. You can also click on the "Examples" link in the breadcrumb trail, and it will scroll down even though it's the same URL, fragment and all.  However, it should automatically scroll down like this when the page is first loaded.

I originally thought this was happening only because I was doing "Open Link in New Tab", but it happens when simply clicking on the link also.


Reproducible: Always

Steps to Reproduce:
1. Go to a page that has links with fragment identifiers, such as http://www.HTML-5.com/examples/
2. Click on one of the links with a fragment identifier - does NOT scroll down automatically as expected
3. Copy and paste the URL into another tab - still does NOT scroll down automatically as expected
4. After the page has loaded, position the cursor at the end of the URL in the address bar and hit Return. NOW it scrolls down as expected.
Actual Results:  
Scrolling area of browser is positioned at the top of the page

Expected Results:  
Scrolling area of browser should be positioned so that the HTML element with the id attribute matching the fragment identifier is visible.
Comment 1 Ed Morley [:emorley] 2011-03-25 16:11:00 PDT
Confirmed with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110325 Firefox/4.2a1pre ID:20110325030426
Comment 2 Ed Morley [:emorley] 2011-03-25 16:29:12 PDT
Last good nightly: 2010-05-15 
First bad nightly: 2010-05-16

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=932c6dc1932b&tochange=3054ada929a2

Perhaps this?
-> Timothy Nikkel — Bug 559996. Lazy frame construction can sometimes cause a subdocument to not scroll to ref in url. r=jst
http://hg.mozilla.org/mozilla-central/rev/8cde1892b3d4

Note: Weirdly enough, if NoScript is currently blocking the JS on html5.com; the scrolling occurs fine, if scripts are allowed; scrolling does not occur.
Comment 3 Ed Morley [:emorley] 2011-03-25 17:28:00 PDT
See also bug 638753 (albeit different regression range).
Comment 4 Rob Simpson 2011-03-28 07:21:46 PDT
Shawn Rhode (in Bug 638753):
>>Quote>> I was not attempting to say that the two bugs were the same issue (although based on the description of 645075 provided by the opener, ...

The original description on this bug was: Clicking on link with fragment identifier does not automatically scroll to element with that id="..."

I was unable to find any similar bugs myself. Someone later found the Ars Technica bug, and possibly changed the description at that time, maybe before it was discovered that the two had two different ranges of regression.

So I suspect the similarity in the descriptions was simply to make it more consistent in how the two bugs with similar outcomes were described.

One thing that is similar between those two sites is that Ars Technica uses a <div id> as the target of the link and http://www.HTML-5.com/ uses the more-specific-type-of-<div> <section id> as the target, even though the former is XHTML 1.0 Transitional and the latter is Valid HTML 5 according to the W3C Markup Validation Service.

Thanks all! I'll watch for the fix for the other bug and see if by chance it fixes this one also. It's possible the code that was regressed in two different places at two different times only needs to be in one place or the other for the scrolling to (targets of fragment identifiers formerly known as anchors) to work.
Comment 5 Rob Simpson 2011-03-28 07:56:52 PDT
Additional test case, possibly with a different regression range.

>>Quote Shawn Rhode in Bug 638753>> In this case [Bug 638753], the issue is that the anchor isn't being honored on reload of a page when retrieving additional content on the page using a link. In the other case [Bug 645075], it would seem the issue is that the anchor isn't being honored when going to a page the first time with a URL that contains the anchor in it.  Similar outcomes but two slightly different behaviors.

In addition to the "anchor isn't being honored on reload of a page when retrieving additional content" behavior on a single story, the Ars Technica site also exhibits the same "anchor isn't being honored when going to a page the first time" as http://www.HTML-5.com/ as described in this bug.

Test case (not sure if this is a test case for this bug or Bug 638753 yet - depends on the regression range):

1. Go to the Ars Technica home page at http://www.ArsTechnica.com/.
2. Click on the "COMMENT" link under any story.
   -> The first time the page loads it stays scrolled to the top.
3. Position the cursor in the address bar and hit Return.
   -> Now it scrolls to where you would have expected.
Comment 6 Siddhartha Dugar [:sdrocking] 2011-04-13 05:57:50 PDT
See Bug 596512
Comment 7 JP Rosevear [:jpr] 2011-04-13 12:17:02 PDT
This is not a regression from FF4 and since shipped it does not make sense to backout a patch from almost a year ago.  There is also no proposed patch.

This should be looked and and fixed if possible on mozilla-central for future release trains.
Comment 8 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-04-13 13:22:23 PDT
No testcase associated to the bug, so removing 'testcase' keyword.
Comment 9 Timothy Nikkel (:tnikkel) 2011-04-13 21:58:03 PDT
What happens here is that we have an XSL transformation and we call SetChangeScrollPosWhenScrollingToRef(true) on the original document. But we call ScrollToRef on the transformed document, and ChangeScrollPosWhenScrollingToRef is false on that document, so we do no scrolling.

It seems that moving this ScrollToRef functionality to the document from the content sink in bug 559996 was a mistake. We just need to be able to call ScrollToRef from the document viewer, so we can just forward the document->ScrollToRef call there to the content sink via the document.
Comment 10 Timothy Nikkel (:tnikkel) 2011-04-13 21:59:40 PDT
Created attachment 525931 [details] [diff] [review]
patch

Move the ScrollToRef stuff from the document back to the content sink.
Comment 11 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-04-25 17:46:28 PDT
An alternative approach would be to simply copy the scroll data from the old document to the new one in the XSLT case. I don't have strong feelings either way.

Let me know what solution you think is best.
Comment 12 Timothy Nikkel (:tnikkel) 2011-04-25 21:37:10 PDT
I considered that approach too, it seemed more fragile, but I don't have a preference either way.
Comment 13 VeRtex 2011-05-03 03:31:28 PDT
Confirmed.
If you disable JavaScript, it does not work either.
Mozilla/5.0 (Windows NT 6.1; rv:6.0a1) Gecko/20110502 Firefox/6.0a1
Comment 14 Danny Althoff 2011-05-06 09:16:18 PDT
(In reply to comment #5)
> 1. Go to the Ars Technica home page at http://www.ArsTechnica.com/.
> 2. Click on the "COMMENT" link under any story.
>    -> The first time the page loads it stays scrolled to the top.
> 3. Position the cursor in the address bar and hit Return.
>    -> Now it scrolls to where you would have expected.

When i open a page with comment, first my browser doesnt scroll down, when i click on the "back" button and click on the link again, the browser does jump down, without hitting ENTER in the url-bar.

I'm using latest normal-release
Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Comment 15 Timothy Nikkel (:tnikkel) 2011-05-06 09:19:19 PDT
The ArsTechnica bug is a different bug (bug 638753) and it isn't fixed in Firefox 4.0.1. If you want the fix for bug 638753 then you could try Aurora or nightlies or wait until Firefox 5.
Comment 16 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-05-10 16:07:46 PDT
Comment on attachment 525931 [details] [diff] [review]
patch

Gah, sorry for the slow review!
Comment 17 Timothy Nikkel (:tnikkel) 2011-05-12 09:09:44 PDT
Landed
http://hg.mozilla.org/mozilla-central/rev/ed867467d35b

but backed out because it didn't build on at least Mac
http://hg.mozilla.org/mozilla-central/rev/b135939df49e

I thought I had try servered this, but perhaps I misremembered.
Comment 18 Timothy Nikkel (:tnikkel) 2011-05-18 09:32:58 PDT
My revised patch fails content/test/reftest/bug559996.html and parser/htmlparser/tests/reftest/bug582940-1.html.
Comment 19 Ruvim Pinka 2011-06-23 15:55:23 PDT
*** Bug 666718 has been marked as a duplicate of this bug. ***
Comment 20 Ruvim Pinka 2011-11-08 09:56:12 PST
Firefox 8 realized. The bug is still alive :(
Comment 21 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-11-08 09:59:41 PST
Yes, this bug is still open, which means it isn't fixed yet.
Comment 22 jon.hertzig 2012-03-18 16:41:15 PDT
Anchors seem to work if either Javascript is disabled in the browser, or the page *has some Javascript*.   So here's a workaround:

Add some dummy Javascript to the page, for example: 

<head><script type="text/javascript">document.write("")</script></head>
Comment 23 Rob Simpson 2012-03-19 06:50:23 PDT
Great, thanks, Jon!
Comment 24 Hayo Baan 2012-06-05 03:19:43 PDT
Workaround doesn't seem to work for me :-(

The page still does not go to the anchor at initial load. However, when I click on a link that goes to an anchor on the same page, it does work. So the problem is only at initial load of the page…

Hope this gets resolved soon.
Comment 25 Timothy Nikkel (:tnikkel) 2012-11-08 11:36:11 PST
Created attachment 679762 [details] [diff] [review]
unbitrotted

Still fails
403 ERROR TEST-UNEXPECTED-FAIL | /tests/docshell/test/test_bug653741.html | Original Y offset is not 0.
404 ERROR TEST-UNEXPECTED-FAIL | /tests/docshell/test/test_bug653741.html | Correct offset after reloading page. - got 435, expected 0
REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/talos-slave/test/build/reftest/tests/content/test/reftest/bug559996.html | image comparison (==), max difference: 255, number of differing pixels: 28352
REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/talos-slave/test/build/reftest/tests/layout/reftests/svg/fragmentIdentifier-01.xhtml | image comparison (==), max difference: 255, number of differing pixels: 30000
REFTEST TEST-UNEXPECTED-FAIL | file:///home/cltbld/talos-slave/test/build/reftest/tests/parser/htmlparser/tests/reftest/bug582940-1.html | image comparison (==), max difference: 255, number of differing pixels: 2515
Comment 26 jon.hertzig 2013-02-07 18:31:09 PST
Well the bug is still there (or has resurfaced, at least as of v15). 

Found that you can have an even simpler workaround -- the "empty statement", like this: 

<head><script type="text/javascript">;</script></head>
Comment 27 DennisK 2013-03-05 04:40:13 PST
Also a problem when the anchor is in an XML/XSLT document...

http://kowallekfamily.com/genealogy/reports/desc-4960.xml#A_1503

This URL works fine on an old PC running FF3.6.

Please test this case if and when this bug is fixed.
Comment 28 Rob S. 2013-03-05 06:37:02 PST
Re: http://kowallekfamily.com/genealogy/reports/desc-4960.xml#A_1503

Confirmed with Firefox 19.0.  If you reposition the cursor to the address bar and hit enter, then in scrolls to the anchor.
Comment 29 johnswilkinson 2013-03-06 01:34:08 PST
Agree with DennisK. I have an XML application where the XSLT generates a link to another XML document. Used to work fine in Firefox 3, but hasn't worked since. It does work in Opera and even IE. Have had to code a work-around which refreshes the page after load, which obviously doubles the time it takes and can be confusing for the end-user.
Comment 30 Michael Bakonyi 2013-07-23 03:14:55 PDT
Bug seems still to be present within FF 22 on Mac OS X.
Comment 31 DennisK 2014-03-09 13:33:32 PDT
(In reply to DennisK from comment #27)

Using FF 27.0.1

Another XML related bug that appears to have been there since at least FF 19. Here's a screenshot ... http://kowallekfamily.com/temp/2014-03-09_161530.png

Notice the whitespace to the right and bottom of the client area.

Actual URL is http://kowallekfamily.com/genealogy/reports/toc.xml

If you maximize or resize the window, the client area repaints correctly.

I don't know if this has been reported elsewhere. Lack of interest in fixing XML related bugs discourages me from spending more time on this.
Comment 32 Ruvim Pinka 2014-04-24 13:00:30 PDT
(In reply to DennisK from comment #31)
> Another XML related bug ...
> Notice the whitespace to the right and bottom of the client area.
This issue isn't reproduced in given testcase in Firefox 28.0. BTW, it is better to fill a separate bug report for a different issue.
Comment 33 Ruvim Pinka 2014-04-24 13:18:52 PDT
Regarding Scrolling to anchor — I suspect that the problem is connected with Bug 325891. Can anyone confirm this idea?
Comment 34 DennisK 2014-04-24 13:33:46 PDT
Things worked fine in FF3.6. 325891 seems to have been logged years earlier.
Comment 35 Johan 2014-07-04 04:55:49 PDT
The simplest work-around is doing location.href+=''.
Comment 36 DennisK 2014-07-04 05:11:01 PDT
(In reply to Johan from comment #35)
> The simplest work-around is doing location.href+=''.

Bingo! That works great.
Comment 37 Hayo Baan 2014-07-06 11:56:31 PDT
(In reply to Johan from comment #35)
> The simplest work-around is doing location.href+=''.

Where/how would I add that piece of code? Adding it to a piece of code that is run when the page gets loaded results in an endless loop of the page reloading itself endlessly…
Comment 38 DennisK 2014-07-06 13:16:04 PDT
> > The simplest work-around is doing location.href+=''.
> 
> Where/how would I add that piece of code? Adding it to a piece of code that
> is run when the page gets loaded results in an endless loop

In body.onload. I had to wrap it as follows to avoid the endless loop...

if (location.href.indexOf('#') > -1)
{
   location.href+='';
}
Comment 39 Hayo Baan 2014-07-07 00:12:15 PDT
(In reply to DennisK from comment #38)
> In body.onload. I had to wrap it as follows to avoid the endless loop...
> 
> if (location.href.indexOf('#') > -1)
> {
>    location.href+='';
> }

Awesome, works fine now!
(I have put it in $(document).ready, but the result is the same: anchors now (finally) work as expected :-)
Comment 40 Dave Merrill 2014-07-07 03:49:57 PDT
I know this isn't super helpful, but 3+ years after this was reported, how is it that this basic functionality is still broken is the latest ESR (24.6.0)? It's great that there's a workaround, thanks for that, but the continued existence of this bug is still pretty surprising. Everyone just expects this to work, like it does in other browsers, and used to in Firefox.

I'm not a coder on a level that can work on this myself, so I have no right to say anything, but either fixing this is much harder than it looks, or it's been given unduly low priority. Fancy new features are great and all, but chop wood, carry water -- get the basics working too.
Comment 41 Dave Merrill 2014-07-07 04:00:14 PDT
My apologies, it's not that simple. The example given in the original bug report still doesn't work for me with ESR 24.6.0, but my own app where I first ran into this issue does. Works when opening a new window, and when clicking fragment links within the current document.

Not sure what exactly this means, but in any case, it seems that the situation is possibly improved, but not fully settled.
Comment 42 wladimirschaefer 2015-01-09 20:13:41 PST
That is some weird one, I have a couple of anchors, some of them work, others not. Absolutely same code, for one page go, for another one no-go. Whatta..?! Drives me nuts. Six simple Pages WP base site, I can set anchors for all except one of that six pages. IIt works _in_page like it should, but from the outside two of the three anchors in that page jump to the bottom of the page. JS off -> all good, click on adress bar and enter -> all great. Just crazy.

FF 33.0.1/ArchLinux
Comment 43 Marc Löhe 2015-02-05 12:01:22 PST
I just stumbled upon a workaround for this bug in some old source (Sphinx JS code from 2007 if anybody was wondering: https://github.com/sphinx-doc/sphinx/blame/dfc0a6c7f4af900e3d34d6a19311219ddf1fca65/sphinx/themes/basic/static/doctools.js#L177) and wanted to check whether the legacy code can be removed nowadays.

Actually I just tried to replicate the instructions from the original bug descriptions (using http://www.html-5.com/examples/index.html as an example) with FF 35.0.1 on Ubuntu 12.04.5 and actually: yes this bug is still alive and kicking.

Is there anyone keeping an eye on it? It would be great to have this one solved after years. I'm sorry I can't be of any help because of a lack of knowledge in the FF codebase, but I hope reporting the bug still helps fixing it. Please tell me if I can be of any help in providing information etc.

Thanks for the workaround posted here, though, this is a lot better than the one in the Sphinx codebase because it doesn't rely on UA sniffing.
Comment 44 Martijn Wargers [:mwargers] (not working for Mozilla) 2015-02-06 10:28:42 PST
Created attachment 8560590 [details] [diff] [review]
scrollcontentsink.diff unbitrotted again

I unbitrotted the latest unbitrotted patch from Timothy Nikkel again. I hope I did it right.
I pushed it to try to see if the failures are still occuring: https://tbpl.mozilla.org/?tree=Try&rev=c51d2e7f4b1e
Comment 45 Martijn Wargers [:mwargers] (not working for Mozilla) 2015-02-06 14:10:02 PST
Created attachment 8560709 [details] [diff] [review]
scrollcontentsink_b.diff

Tryserver only showed failures in layout/reftests/scrolling/deferred-anchor.xhtml#d and layout/reftests/scrolling/deferred-anchor2.xhtml

I made some changes in those reftests to see if it would fix the failures:
https://tbpl.mozilla.org/?tree=Try&rev=4cb4fbb66a46
Not sure if those changes are valid, though.
Comment 46 Martijn Wargers [:mwargers] (not working for Mozilla) 2015-02-06 17:14:41 PST
Ok, layout/reftests/scrolling/deferred-anchor.xhtml#d and layout/reftests/scrolling/deferred-anchor2.xhtml keep failing on reftest. Strangely enough, those reftest don't fail for me when loading in a regular browser.

Timoty, perhaps you can take a look at this again?
Comment 47 Penelope Fudd 2016-03-22 13:41:37 PDT
Confirming this bug is present in Firefox 45.0 on Ubuntu 12.04.5.
Comment 48 mchavarriagam 2016-08-10 16:14:20 PDT
Can replicate on Ubuntu 14.04, Firefox 47.

Note You need to log in before you can comment on or make changes to this bug.