337342 - Sort out how to implement section 4.9.4 of WHATWG WebApps

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Boris Zbarsky [:bzbarsky]]

The text in question is:

    When a new top-level browsing context is created by a script in an existing
    browsing context, or by the user following a link in an existing browsing
    context, or in some other way related to a specific DocumentWindow, then, if
    the new context's first DocumentWindow has the same domain as the
    DocumentWindow from which the new context was created, the new browsing
    context must start with a single session storage area. That storage area
    must be a copy of that domain's session storage area in the original
    browsing context, which from that point on must be considered separate, with
    the two storage areas not affecting each other in any way.

Issues I see here wrt interaction with our implementation (per bug 335540):

1)  Our impl doesn't handle <a target="whatever"> right when this creates a new
    window.
2)  Our impl copies the storage stuff over when doing window.open() into an
    already-existing window.  I can't tell from the spec whether this is
    correct.
3)  At the time a new "browsing context" is created (indeed, at the time its
    DocumentWindow is created), it's not known what domain it has.  This
    information is not available until the server response, in fact, given
    redirects.  I'm not sure what the spec intends should happen here,
    especially if the storage APIs are queried between the time when the window
    is created and the time when the domain is known.

It'd be good to fix point #1 (how?) and get points #2 and #3 clarified in the spec so we can figure out how to implement them.

Comment 1

[Johnny Stenback (:jst)]

The lates patch in bug 335540 (attachment 221904 [details] [diff] [review]) fixes a good bit of this, except the things that aren't clear in the spec.

Comment 2

[Hixie (not reading bugmail)]

I changed the quoted paragraph to:

   When a new top-level browsing context is created by a script in an existing 
   browsing context, or by the user following a link in an existing browsing 
   context, or in some other way related to a specific HTMLDocument, then the 
   session storage area of the origin of that HTMLDocument must be copied into 
   the new browsing context when it is created. From that point on, however,
   the two session storage areas must be considered separate, not affecting 
   each other in any way. 

...which is hopefully simpler and addresses these issues. Let me know if I missed something. (Note in particular that window.open() to an existing window has no effect on session storage APIs per spec.)

Comment 3

[Neil Deakin]

Is any of this still relevant?

Comment 4

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.