- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 19 Jun 2011 23:10:46 -0400
- To: Adam Barth <ietf@adambarth.com>
- CC: public-iri@w3.org
On 6/19/11 5:47 PM, Adam Barth wrote:
> Does that mean if a new document arises from evaluating the JavaScript
> URL that you'll scroll the page to the indicated fragment?
Yes, but Firefox 4 and earlier does that too, because the "scroll to
fragment" code doesn't actually use the results of parsing the URI (long
story that I'm happy to fill people in on if desired) and instead
serializes it to a string and then just grabs everything after the first
'#'.
Testcase:
<iframe src="javascript:'<html><div style="height:
1000px"></div><div
id="test\'">test</div></html>#test'"></iframe>
> In the resulting document, will location.hash contain the part after the # ?
Yes (this will be a behavior change from Firefox 4). Testcase:
<iframe
src="javascript:'<html><script>alert(location.hash);</script></html>#test'"></iframe>
> What will assigning to location.hash do (e.g., re-evaluating the
> JavaScript URL or just scroll the page)?
Just scroll the page. This will be a behavior change from Firefox 4,
where I believe the set was ignored entirely. Testcase:
<iframe src="javascript:alert('running'); '<html><div
style="height: 1000px"></div><div
id="test">test</div><script>location.hash="test"</script></html>'"></iframe>
Note that those first two behaviors are arguably a violation of the
current HTML5 drafts, because the URI of a javascript:-generated
document is not supposed to be a javascript: URI per those drafts. So
you're right that the change Gecko is making is black-box detectable
using location.hash for the moment, but once we implenent the HTML5 spec
on this (assuming it doesn't change) it may not be....
-Boris
Received on Monday, 20 June 2011 03:11:15 UTC