html-5.com - Scrolling to anchor fails in Firefox 4 (works fine if javascript disabled)

NEW
Assigned to

Status

()

Core
DOM
--
major
6 years ago
10 months ago

People

(Reporter: Rob Simpson, Assigned: tnikkel, NeedInfo)

Tracking

({regression})

Trunk
x86
Windows 7
regression
Points:
---

Firefox Tracking Flags

(firefox5-)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
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.
Confirmed with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110325 Firefox/4.2a1pre ID:20110325030426
Keywords: regression, regressionwindow-wanted
Version: unspecified → Trunk
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.
Blocks: 559996
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Keywords: regressionwindow-wanted → testcase
Product: Firefox → Core
QA Contact: general → general
See also bug 638753 (albeit different regression range).
Summary: Clicking on link with fragment identifier does not automatically scroll to element with that id="..." → html-5.com - Scrolling to anchor fails in Firefox 4 (works fine if javascript disabled)
(Assignee)

Updated

6 years ago
Assignee: nobody → tnikkel
(Reporter)

Comment 4

6 years ago
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.
(Reporter)

Comment 5

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

Updated

6 years ago
tracking-firefox5: --- → ?
See Bug 596512

Updated

6 years ago
Blocks: 596512

Comment 7

6 years ago
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.
tracking-firefox5: ? → -
No testcase associated to the bug, so removing 'testcase' keyword.
Keywords: testcase
(Assignee)

Updated

6 years ago
No longer blocks: 596512
(Assignee)

Comment 9

6 years ago
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.
(Assignee)

Comment 10

6 years ago
Created attachment 525931 [details] [diff] [review]
patch

Move the ScrollToRef stuff from the document back to the content sink.
Attachment #525931 - Flags: review?(jonas)
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.
(Assignee)

Comment 12

6 years ago
I considered that approach too, it seemed more fragile, but I don't have a preference either way.

Comment 13

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

6 years ago
(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
(Assignee)

Comment 15

6 years ago
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 on attachment 525931 [details] [diff] [review]
patch

Gah, sorry for the slow review!
Attachment #525931 - Flags: review?(jonas) → review+
(Assignee)

Comment 17

6 years ago
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.
(Assignee)

Comment 18

6 years ago
My revised patch fails content/test/reftest/bug559996.html and parser/htmlparser/tests/reftest/bug582940-1.html.

Updated

6 years ago
Duplicate of this bug: 666718

Comment 20

6 years ago
Firefox 8 realized. The bug is still alive :(
Yes, this bug is still open, which means it isn't fixed yet.

Comment 22

5 years ago
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>
(Reporter)

Comment 23

5 years ago
Great, thanks, Jon!

Comment 24

5 years ago
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.
(Assignee)

Comment 25

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

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

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

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

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

4 years ago
Bug seems still to be present within FF 22 on Mac OS X.

Comment 31

3 years ago
(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

3 years ago
(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

3 years ago
Regarding Scrolling to anchor — I suspect that the problem is connected with Bug 325891. Can anyone confirm this idea?

Comment 34

3 years ago
Things worked fine in FF3.6. 325891 seems to have been logged years earlier.

Comment 35

3 years ago
The simplest work-around is doing location.href+=''.

Comment 36

3 years ago
(In reply to Johan from comment #35)
> The simplest work-around is doing location.href+=''.

Bingo! That works great.

Comment 37

3 years ago
(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

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

3 years ago
(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

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

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

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

2 years ago
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.
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
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.
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?
Flags: needinfo?(tnikkel)
See Also: → bug 1241143
See Also: → bug 633434

Comment 47

a year ago
Confirming this bug is present in Firefox 45.0 on Ubuntu 12.04.5.

Comment 48

10 months ago
Can replicate on Ubuntu 14.04, Firefox 47.
You need to log in before you can comment on or make changes to this bug.