1457458 - Rewrite AboutCapabilities.webidl in C++

Status: RESOLVED DUPLICATE of bug 1459204

(Core :: DOM: Security, enhancement, P2)

Description

[Christoph Kerschbaumer [:ckerschb]]

Based on the fact that we are going to deprecate JS implemented WebIDL (see 
Bug 1450827) we have to rewrite AboutCapabilities in C++.

Comment 1

[Christoph Kerschbaumer [:ckerschb]]

Attachment: bug_1457458_rewrite_aboutcapabilities.patch

Gijs, I am adding a WIP patch of how aboutcapabilities will roughly look like once converted to C++, however I got two questions:

1) SetBoolPref and SetCharPref will need to be remoted, because obviously we can't set the pref in a non parent process. To my understanding we can't access AsyncPrefs, is there a good alternative or how do you think we can best handle updating prefs?

2) At the moment I don't fully understand how to best implement SendAsyncMessage. Do you have any pointers how to move forward with the implementation of SendAsyncMessage?

Am I missing anything else?

Comment 2

[:Gijs (out for now; he/him)]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1)
> Created attachment 8971565 [details] [diff] [review]
> bug_1457458_rewrite_aboutcapabilities.patch
> 
> Gijs, I am adding a WIP patch of how aboutcapabilities will roughly look
> like once converted to C++, however I got two questions:

I've tried to answer these, but I will note that actually:

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #0)
> Based on the fact that we are going to deprecate JS implemented WebIDL (see 
> Bug 1450827) we have to rewrite AboutCapabilities in C++.

"have to" seems quite strong. :-)

We could also just ditch the webidl approach.

I like strong guarantees for this stuff a lot, but given almost all the consumers of this API, as well as the people who need to modify it, will be frontend engineers, it should ideally be possible for them to use/modify it. By moving the implementation into C++ (or Rust!) that becomes harder.

I think given that, we should consider moving to the remote channel stuff that Mossop pointed out after this was first implemented, instead of making the story worse from a maintenance/adaptability perspective.

> 1) SetBoolPref and SetCharPref will need to be remoted, because obviously we
> can't set the pref in a non parent process. To my understanding we can't
> access AsyncPrefs, is there a good alternative or how do you think we can
> best handle updating prefs?

I don't know. I guess we could consider piggybacking on the messagemanager API that AsyncPrefs exposes, but that seems pretty ugly. Short of that we'd have to mimic a similar thing in C++ which also seems ugly.

> 2) At the moment I don't fully understand how to best implement
> SendAsyncMessage. Do you have any pointers how to move forward with the
> implementation of SendAsyncMessage?

I'm not really sure what the question is. Presumably through webidl you get some references to the scope/document/frame/window to which the instance is attached, and can get the message manager off there, and then send the data that way?

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

An update on this bug: We decided to bring some of the benefits of AboutCapabilities into the RemotePageManager and hence decided to have about:privatebrowsing rely on RPM.

This bug has essentially become invalid, but I think it makes more sense to mark it as a duplicate of Bug 1459204.