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

On Thu, 13 Sep 2007, Mihai Sucan wrote:
> 
> 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).

Fixed.


> 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.

No, the three bullet points are about security. The bit you quote is just 
to give the user agents a chance to improve UI if desired.

I think the current text is fine. We don't gain anything by making the 
text more complicated here.


> 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.

Fixed.


> 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).

I started fixing this (the intent was that the events be fired on the 
documents they belonged to, not documents from other origins), but as I 
did so I found a number of serious issues in the way state objects were 
specified. I have attempted to fix all these issues.


> 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.

Fixed.


> 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.

This became a non-issue with the changes described above.


> 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."
> 
> Correction:
> 
> "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."

Fixed the two errors.


> 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 
> window.location.assign.
> 
> Weird. Please fix that. :)

The reason is visible if you look at the source of the document. 
location.href's setter is actually a lot more complicated than currently 
specified, but that complexity is currently commented out.

I've made a note to myself to remember to fix this if we decide to not use 
the currently-commented-out text.


> 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 
> provide".

No, the current text is accurate. "It is suggested that the UA provide" is 
correct English. We don't want any RFC2119-strength words here, as this is 
a UI concern and not an interop concern.


Thanks again for the detailed feedback! Your continued support is very 
useful and valued.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 16 February 2008 01:16:04 UTC