Closed Bug 645075 Opened 13 years ago Closed 2 years ago

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

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows 7
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox5 - ---

People

(Reporter: Rob.Simpson, Assigned: tnikkel)

References

()

Details

(Keywords: regression)

Attachments

(4 files)

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
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
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: nobody → tnikkel
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.
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.
Blocks: 596512
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.
No testcase associated to the bug, so removing 'testcase' keyword.
Keywords: testcase
No longer blocks: 596512
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.
Attached patch patchSplinter Review
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.
I considered that approach too, it seemed more fragile, but I don't have a preference either way.
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
(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
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+
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.
My revised patch fails content/test/reftest/bug559996.html and parser/htmlparser/tests/reftest/bug582940-1.html.
Firefox 8 realized. The bug is still alive :(
Yes, this bug is still open, which means it isn't fixed yet.
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>
Great, thanks, Jon!
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.
Attached patch unbitrottedSplinter Review
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
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>
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.
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.
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.
Bug seems still to be present within FF 22 on Mac OS X.
(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.
(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.
Regarding Scrolling to anchor — I suspect that the problem is connected with Bug 325891. Can anyone confirm this idea?
Things worked fine in FF3.6. 325891 seems to have been logged years earlier.
The simplest work-around is doing location.href+=''.
(In reply to Johan from comment #35)
> The simplest work-around is doing location.href+=''.

Bingo! That works great.
(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…
> > 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+='';
}
(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 :-)
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.
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.
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
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.
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
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: → 1241143
See Also: → 633434
Confirming this bug is present in Firefox 45.0 on Ubuntu 12.04.5.
Can replicate on Ubuntu 14.04, Firefox 47.
Component: DOM → DOM: Core & HTML

Marking this as Resolved > Worksforme since the issue is no longer reproducible on the latest versions of Firefox Nightly 96.0a1 (2021-11-23), beta 95.0b10 or release 94.0.2 on Windows 10, Ubuntu 20.04 and Windows 7.
If anyone is still able to reproduce this issue either re-open this ticket or file a new one.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(tnikkel)
You need to log in before you can comment on or make changes to this bug.