- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 16 Feb 2008 01:15:52 +0000 (UTC)
- To: Mihai Sucan <mihai.sucan@gmail.com>
- Cc: public-html <public-html@w3.org>
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