W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Detailed review of 4.1. Browsing contexts and 4.3. Session history and navigation

From: Mihai Sucan <mihai.sucan@gmail.com>
Date: Thu, 13 Sep 2007 14:29:22 +0300
To: public-html <public-html@w3.org>
Message-ID: <op.tylbi8qdmcpsjgr0b0dp@athlon>


I have reviewed the section 4.1. "Browsing contexts" [1] from the HTML 5  
specification. I have several comments to make.

1. In the introduction of the section, the last paragraph, first phrase,  
there's a typo:

"When a browsing context is first created, it must be created with a  
single Document in its session history, whose address is about:blank,  
which is marked as being an *HTML documents*."

Correction: HTML document (not documents).

2. In section 4.1.5. "Browsing context names" [2], step 4, first  
paragraph, first phrase, after the unordered list:

"...and the user agent determines that the two browsing contexts are  
related enough that it is ok if they reach each other, then that browsing  
context must be the chosen one."

"it is ok if they reach other"? That doesn't "sound" too nice. I'd suggest  
"related enough that it is considered safe if they reach other". It's  
about security/safety after all.

Next related section 4.3. "Session history and navigation" [3]:

1. In section 4.3.1. "The session history of browsing contexts" [4], first  
paragraph, immediately after the first note:

"URIs without *assaciated* state objects are added to the session history  
as the user (or script) navigates from page to page."

Typo correction: associated.

2. Step 3 in the history traversal algorithm [5] defined in section 4.3.2.  
"The History interface" [6], says:

"If there are any entries with state objects between the current entry and  
the specified entry (not inclusive), then the user agent must iterate  
through every entry between the current entry and the specified entry,  
starting with the entry closest to the current entry, and ending with the  
one closest to the specified entry. For each entry, if the entry is a  
state object, the user agent must activate the state object."

Does this mean that all the state objects are activated when the UA  
traverses to the target entry, when leaving the page, in the "previous"  
document ? Such that, if I am on page A going to page B, the script on  
page A can have an event listener which uses all the state objects stored  
in *all* pages found in the session history between A and B?

If yes, where are the security-related restrictions? Same origin, maybe  
same document. Does the UA have to activate state objects stored on other  
pages/domains which were viewed in the same session between page A and B?

Again, if yes, the popstate event should also include a "location"  
attribute, so scripts can check where the state object comes from (which  
page). The attribute could be defined with similar properties like the  
Window Location object (location.hostname ... port, etc).

3. The PopStateEvent IDL [7] has a typo:

"void initPopStateEvent(in DOMString typeArg, in boolean canBubbleArg, in  
boolean cancelableArg, in DOMObject *statetArg*);"

Make statetArg = stateArg.

4. "Big Issue: Should we coalesce these events if they occur while the  
page is away? (e.g. during traversal -- see above)"

The answer is yes. By coalescing multiple PopStateEvents into a single  
one, scripts would run faster and would be able to manipulate easier the  
state objects.

5. In section 4.3.4. "The Location interface" [8], the second paragraph  
after the PRE.idl has some typos:

"In the ECMAScript DOM binding, the location members of the HTMLDocument  
and Window interfaces behave as if they had a setter: user agents must  
*treats* attempts to set these location *attribute* as attempts at setting  
the href attribute of the relevant Location object instead."


"In the ECMAScript DOM binding, the location members of the HTMLDocument  
and Window interfaces behave as if they had a setter: user agents must  
treat attempts to set these location attributes as attempts at setting the  
href attribute of the relevant Location object instead."

6. In the same section 4.3.4. [8], about the same paragraph:

Why setting the location attribute is defined as setting the href  
attribute of the relevant Location object? Setting the location attribute  
should be directly defined as invoking the assign() method (of the  
relevant Location object) with the provided value.

I'm saying this because, two paragraphs later, setting the location.href  
attribute is itself defined as:

"The href attribute returns the address of the page represented by the  
associated Document object, as an absolute IRI reference. On setting, the  
user agent must act as if the assign() method had been called with the new  
value as its argument."

So basically, currently the spec says: when one tries to set  
window.location, try to set window.location.href, but actually invoke  

Weird. Please fix that. :)

7. In section 4.3.5. "Implementation notes for session history" [9], the  
second last paragraph has an error:

"Security: It is suggested that to avoid letting a page "hijack" the  
history navigation facilities of a UA by abusing pushState(), *the UA  
provide* the user with a way to jump back to the previous page (rather  
than just going back to the previous state). ..."

Probably the emphasized part of the quote needs to be "the UA should  

That's about all for now.


Received on Thursday, 13 September 2007 11:29:38 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:21 UTC