Closed Bug 516293 Opened 15 years ago Closed 10 years ago

Setting document.location.hash to a not-yet-loaded element does nothing

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1054289

People

(Reporter: ayg, Unassigned)

Details

(Keywords: helpwanted, html5, student-project)

Attachments

(1 file)

location.hash.html
151 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/4.0.207.0 Safari/532.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2

Consider the following test page:

<!doctype html>
<title>test</title>
<script>document.location = "#frag"</script>
<div style="margin-top: 100em"></div>
<p id=frag>Jump to me!</p>

Observed behavior in both Chrome 4 and Opera 9.6 is that the browser jumps to the given fragment; Firefox 3.5 does not.  I believe all versions of IE jump to the fragment as well, since MediaWiki relies on this, although I haven't personally tested.

The issue is, of course, that at the time document.location is set, no element with id "frag" exists in the document.  However, IMO it's expected that setting a fragment should cause the same behavior as if the user had navigated to the document with that fragment to begin with -- namely, that the UA jumps to the fragment when it loads.

I brought this up on the whatwg list <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022578.html>, and Ian changed the spec to support the other browsers' behavior:

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid

MediaWiki currently uses a UA-sniffing workaround for this, and it would be nice if we could turn it off for newer versions of Firefox.  We jump onload instead of immediately, so it's a worse user experience for Firefox users too.

Reproducible: Always

Steps to Reproduce:
1. Paste the HTML from above into a file.
2. Load the file in Firefox.
Actual Results:  
The viewport remains at the top of the page, and the text "Jump to me!" is not visible.

Expected Results:  
The document.location change should cause the browser to jump to the "frag" element.
Attached file location.hash.html — 
conforming...
Status: UNCONFIRMED → NEW
Ever confirmed: true
If someone wants to take this on, what would need to happen would be to consolidate the docshell code that calls GoToAnchor in this situation with the content sink code that tries repeatedly scrolling during the pageload.... possibly by moving the repeated scrolling thing into the presshell.
Keywords: helpwanted, student-project
Keywords: html5
(In reply to Boris Zbarsky (:bz) from comment #2)
> If someone wants to take this on, what would need to happen would be to
> consolidate the docshell code that calls GoToAnchor in this situation with
> the content sink code that tries repeatedly scrolling during the
> pageload.... possibly by moving the repeated scrolling thing into the
> presshell.
What would be the appropriate file to look at in this case? ff 7.01 on vista basic has it
The hack is still in place for Wikipedia, any progress on this bug?


<<<JS

		window.location.hash = fragment;

		// Mozilla needs to wait until after load, otherwise the window doesn't
		// scroll.  See <https://bugzilla.mozilla.org/show_bug.cgi?id=516293>.
		// There's no obvious way to detect this programmatically.
		if ( profile.layout === 'gecko' ) {
			$( function () {
				if ( window.location.hash === fragment ) {
					window.location.hash = fragment;
				}
			} );
		}
JS;
According to comments on bug 1054289, this should be fixed now. Can somebody with appropriate permissions verify and resolve this bug?
Downstream patch, if this is indeed fixed: https://gerrit.wikimedia.org/r/157688
Looks like this is fixed.  I'm marking it a duplicate of bug 1054289 on the assumption that's what fixed it.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: