1329572 - Consider making origin attributes become a XPCOM object

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[Jonathan Hao (inactive) [:jhao]]

Currently, a method with an origin attributes parameter can't be used by both JS and C++.  For JS, the type is "jsval" and for C++ the type is "(Necko/Principal/DocShell)OriginAttributes".

Can we consider making origin attributes become a XPCOM object, so a method can be used by both JS and C++?  One downside is that we can't just use a JS object literal {...} as origin attributes anymore, but we can probably use a factory method to create an origin attributes object.

Comment 1

[Christoph Kerschbaumer [:ckerschb]]

Tanvi, can you assing a priority to this bug as well please?

Comment 2

[Tanvi Vyas[:tanvi]]

baku, what do you think about this?

Comment 3

[Tim Huang[:timhuang]]

(In reply to Jonathan Hao [:jhao] (Away 1/27-2/1) from comment #0)
> Can we consider making origin attributes become a XPCOM object, so a method
> can be used by both JS and C++? One downside is that we can't just use a JS
> object literal {...} as origin attributes anymore, but we can probably use a
> factory method to create an origin attributes object.

An example of the factory method is the factory of the nsILoadContextInfo[1] which is used by Necko. It allows JS code to produce nsILoadContextInfo. We can adopt the same mechanism here after originAttributes be converted into an XPCOM object. By doing so, Javascript can still use a JS object literal to generate an originAttributes XPCOM object them passing into the function.

[1] http://searchfox.org/mozilla-central/source/netwerk/base/nsILoadContextInfo.idl#80

Comment 4

[Andrea Marchesini [:baku]]

I like the idea to have nsIOriginAttributes. But I remember that bholley was strongly again it, if I remember correctly.
Maybe I'm wrong.

Comment 5

[Bobby Holley (:bholley)]

I was against XPCOM-ifying OriginAttributes because it would add a lot of overhead and boilerplate, both in C++ and JS. And there wasn't a use-case that required it.

The general idea has been that C++ consumers should use generally move towards non-XPIDL interfaces to stuff, and therefore the only consumers of the XPIDL APIs would be JS consumers, which would use the jsval signature, because that's how modern webby JS works.

Are there situations where, for some reason, we really need to use the same API in both C++ and JS? In those situations I could imagine the jsval getting in the way for C++ callers. We could add an  nsIOriginAttributesHolder or something for those cases, but I'd rather not use XPIDL for the common case here.

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

Clearing my ni? queue at the moment. It seems that bholly's answer in comment 5 provides the ni? answer from tanvi. Keeping this in the backlog.