Skip to content

Which origins to use in postMessage? #1542

@domenic

Description

@domenic

This is part of #1431 and #1430.

postMessage current uses, per spec:

  • the entry settings object is used for an origin check if targetOrigin is "/"
  • the incumbent settings object to determine the origin and source attributes of the resulting MessageEvent.

I'm having a hard time with black-box testing of these cases, so I'm trying to fall back to code inspection.

Code inspection of Blink reveals that Blink uses the current settings object for both of these: https://chromium.googlesource.com/chromium/src/+/540e575dc43e718821bc4ac682735a9631e33c1f/third_party/WebKit/Source/bindings/core/v8/custom/V8WindowCustom.cpp#176

WebKit uses "callerDOMWindow": https://github.com/WebKit/webkit/blob/152410da081c1a638a3c2b8c0f55b5e726fffd15/Source/WebCore/bindings/js/JSDOMWindowCustom.cpp#L552. I'm not sure what this is supposed to be exactly.

Gecko appears to follow the current spec and use both incumbent and entry: http://searchfox.org/mozilla-central/rev/c44d0b1673fef5e0e2e19fa82d6780a74c186151/dom/base/nsGlobalWindow.cpp#8255, although in an offline email @bzbarsky said

I don't see why entry settings is any better than current settings here, really, assuming the current settings bits get sorted out in such a way that we can use current settings for the source origin here.


With this info in hand I'd say the simplest thing to do here is to converge on current for both. @bzbarsky, do you agree? When I quoted you above you were only referring to the "/" thing, but having them be inconsistent seems bad...

This feels like a classic case of enough browsers disagreeing so that we get to just pick the behavior we think is most reasonable.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions