Using DOM event APIs instead of XPCOM APIs for notifications

[Benjamin Smedberg]

As part of the content-process effort, we are examining various APIs
within gecko which are difficult to use within content processes. Many
of these take the form of XPCOM observers or contractID registrations.
The APIs I know about include:

global HTTP observer topics
(http-on-modify-request/http-on-examine-response/http-on-examine-merged-response/http-on-examine-cached-response)
nsIContentPolicy
nsIConsoleService/nsIConsoleListener
extension-provided nsIStreamConverters
extension-provided URI implementations

In each of these cases, we want to make it easy for extensions using the
message manager to implement equivalent functionality. Because it is
difficult (intentionally) for extensions to register XPCOM components in
content processes, we instead want to change this functionality so that
extensions can implement it using only the message manager.

The basic plan is to redesign these APIs so that they take the form of
DOM events fired at the relevant DOM window. They will propagate to
message manager scripts normally. Most or all of these events will be
chrome-only so that we don't affect web content.

In order to accomplish this, we are going to have to make sure that
every network request in the content process can be associated with a
DOM window. This may be problematic in some cases (right now I know
mainly about problems in the image cache).

In the chrome process, there may be network requests which are
legitimately not associated with any window, for example update pings
and other requests initiated by chrome. To allow handling these cases,
we will introduce a "global" event target to which everything propagates.

As part of this effort, I expect that we will be removing the old
nsIConsole* APIs entirely, and will be making significant improvements
to the content-policy APIs so that they can make some decisions
asynchronously if needed.

Please let me know if you have questions: I'm going to start more
detailed design documents soon, and wanted to post about the general
plan first to clear up any issues.

--BDS

[Neil]

Benjamin Smedberg wrote:

> As part of this effort, I expect that we will be removing the old
> nsIConsole* APIs entirely

It's not always possible to associate console messages/warnings/errors
with windows.

What's going to happen to the stored message array that the Error
Console uses to populate its initial entries?

--
Warning: May contain traces of nuts.

[Benjamin Smedberg]

On 6/17/2011 4:08 PM, Neil wrote:
> Benjamin Smedberg wrote:
>
>> As part of this effort, I expect that we will be removing the old
>> nsIConsole* APIs entirely
>
> It's not always possible to associate console messages/warnings/errors
> with windows.

Those will go to the global event target.

>
> What's going to happen to the stored message array that the Error
> Console uses to populate its initial entries?
>

My plan is not to have the core C++ code store the console messages: we
can store them in JS event for use by the JS console and other code
which wants to have delayed access to the events which matter.

--BDS

[Gavin Sharp]

On Fri, Jun 17, 2011 at 4:16 PM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
>> What's going to happen to the stored message array that the Error Console
>> uses to populate its initial entries?
>>

> My plan is not to have the core C++ code store the console messages: we can
> store them in JS event for use by the JS console and other code which wants
> to have delayed access to the events which matter.

FWIW, we are implementing something very much along those lines in bug
612658 (but for ConsoleAPI a.k.a. window.console.*-generated messages,
rather than nsIConsoleService). Perhaps in the future it could be
extended to support what are today nsIConsoleService messages as well.

Gavin

[smaug]

IIRC, some of the notifications run at time when DOM Events aren't
allowed. For example nsIContentPolicy related things may be called when
there are script blockers in stack - again IIRC.

-Olli

[Boris Zbarsky]

On 6/17/11 6:17 PM, smaug wrote:
> IIRC, some of the notifications run at time when DOM Events aren't
> allowed. For example nsIContentPolicy related things may be called when
> there are script blockers in stack - again IIRC.

This is currently the case. We would need to change that behavior.
That's something we've wanted to do for a while anyway...

-Boris

[johnjbarton]

On 6/17/2011 10:47 AM, Benjamin Smedberg wrote:
> The basic plan is to redesign these APIs so that they take the form of
> DOM events fired at the relevant DOM window. They will propagate to
> message manager scripts normally.

How should we understand the term "message manager scripts"? From
https://developer.mozilla.org/en/The_message_manager
we learn that the message manager is almost-but-sadly-not postMessage
between content and chrome processes. The script running on the content
end of the manager.sendAsyncMessage() is called a content script and
similar for chrome. So is "message manager script" "either content or
chrome script"? Is there any specific characteristic that makes this
JavaScript a "message manager script"?

>
> In order to accomplish this, we are going to have to make sure that
> every network request in the content process can be associated with a
> DOM window. This may be problematic in some cases (right now I know
> mainly about problems in the image cache).
>
> In the chrome process, there may be network requests which are
> legitimately not associated with any window, for example update pings
> and other requests initiated by chrome. To allow handling these cases,
> we will introduce a "global" event target to which everything propagates.

Perhaps you will consider an alternative? I suppose the DOM event API
was selected as an alternative to global observers both because of the
existing and familiar event model and because the DOM provides an easy
to understand container for the JavaScript receiving the event. These
are both good reasons: now apply them consistently.

If all the new notifications used DOM event APIs directed at JavaScript
containers, the architecture of the platform would be clearer. The
current platform has other containers for JavaScript such as sandboxes
and the mysterious BackStagePass. In fact all JS has to have a natural
container associated with its outermost scope. (There is no platform
container for JavaScript called "global").

Of course part of the clarity may result from struggling with the
meaning of this change for the cases not covered. Does it really make
sense to send events to a Sandbox? What do we call the BackStagePass
things and how do we address them? I think facing these questions and
coming up with answers would help the system architecture become clearer
and more useful.

jjb

[smaug]

On 06/18/2011 07:44 PM, johnjbarton wrote:
> On 6/17/2011 10:47 AM, Benjamin Smedberg wrote:
>> The basic plan is to redesign these APIs so that they take the form of
>> DOM events fired at the relevant DOM window. They will propagate to
>> message manager scripts normally.
>
> How should we understand the term "message manager scripts"? From
> https://developer.mozilla.org/en/The_message_manager
> we learn that the message manager is almost-but-sadly-not postMessage
> between content and chrome processes.

postMessage is always async. In message manager we need both
async and sync messaging. Also, _if_ CPOW will be re-enabled, message
manager should be able to send references to js objects.

> The script running on the content
> end of the manager.sendAsyncMessage() is called a content script and
> similar for chrome. So is "message manager script" "either content or
> chrome script"?

In multiprocess setup message manager script is a script which
runs in the content process with chrome privileges.

[Neil]

Benjamin Smedberg wrote:

Sorry, I don't know what you meant when you said "JS event", did you
mean in a JS module, component, or both?

[johnjbarton]

On 6/19/2011 1:40 PM, smaug wrote:
> On 06/18/2011 07:44 PM, johnjbarton wrote:
>> On 6/17/2011 10:47 AM, Benjamin Smedberg wrote:
>>> The basic plan is to redesign these APIs so that they take the form of
>>> DOM events fired at the relevant DOM window. They will propagate to
>>> message manager scripts normally.
>>
>> How should we understand the term "message manager scripts"? From
>> https://developer.mozilla.org/en/The_message_manager
>> we learn that the message manager is almost-but-sadly-not postMessage
>> between content and chrome processes.
> postMessage is always async. In message manager we need both
> async and sync messaging. Also, _if_ CPOW will be re-enabled, message
> manager should be able to send references to js objects.
>
>> The script running on the content
>> end of the manager.sendAsyncMessage() is called a content script and
>> similar for chrome. So is "message manager script" "either content or
>> chrome script"?
> In multiprocess setup message manager script is a script which
> runs in the content process with chrome privileges.

That's a fine definition, but it's not the one used in the documentation:
https://developer.mozilla.org/en/The_message_manager#The_content_script

Consistency would be helpful.
jjb

[Mark Finkle]

On Jun 17, 1:47 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:

> global HTTP observer topics
> (http-on-modify-request/http-on-examine-response/http-on-examine-merged-response/http-on-examine-cached-response)

These examples seem to work in the parent process now, although we
have no connection to a DOM window

> nsIConsoleService/nsIConsoleListener

This is already remoted from child to parent process.

> nsIContentPolicy
> extension-provided nsIStreamConverters

These work pretty easily by manually registering an impl + factory in
a child content script

Maybe I am just getting used to doing things the hard way :)
I have seen devs new to multi-process get tripped up though.

[Benjamin Smedberg]

On 6/18/2011 12:44 PM, johnjbarton wrote:
> On 6/17/2011 10:47 AM, Benjamin Smedberg wrote:
>> The basic plan is to redesign these APIs so that they take the form of
>> DOM events fired at the relevant DOM window. They will propagate to
>> message manager scripts normally.
>
> How should we understand the term "message manager scripts"? From
> https://developer.mozilla.org/en/The_message_manager
> we learn that the message manager is almost-but-sadly-not postMessage
> between content and chrome processes. The script running on the
> content end of the manager.sendAsyncMessage() is called a content
> script and similar for chrome. So is "message manager script" "either
> content or chrome script"? Is there any specific characteristic that
> makes this JavaScript a "message manager script"?

I primarily mean that these messages, if they are associated with
content, will propagate to the content scripts.

>
>
> If all the new notifications used DOM event APIs directed at
> JavaScript containers, the architecture of the platform would be
> clearer. The current platform has other containers for JavaScript such
> as sandboxes and the mysterious BackStagePass. In fact all JS has to
> have a natural container associated with its outermost scope. (There
> is no platform container for JavaScript called "global").

I don't understand this paragraph. What has any of this got to do with
sandboxes?

>
> Of course part of the clarity may result from struggling with the
> meaning of this change for the cases not covered. Does it really make
> sense to send events to a Sandbox? What do we call the BackStagePass
> things

This is specifically about sending events through the DOM, and their
propagation. Sandboxes are not part of the DOM, and cannot receive
events, so they are irrelevant to the proposal here.

--BDS

[Benjamin Smedberg]

On 6/22/2011 1:18 AM, Mark Finkle wrote:
> On Jun 17, 1:47 pm, Benjamin Smedberg<benja...@smedbergs.us> wrote:
>
>> global HTTP observer topics
>> (http-on-modify-request/http-on-examine-response/http-on-examine-merged-response/http-on-examine-cached-response)
> These examples seem to work in the parent process now, although we
> have no connection to a DOM window

Indeed. Most of the extensions which use these events pair them up with
DOM windows through the notification callbacks or other means. I want to
replace this with an explicit method which we can also test.

>> nsIContentPolicy
>> extension-provided nsIStreamConverters
> These work pretty easily by manually registering an impl + factory in
> a child content script

Which is a huge amount of complexity. We're trying to avoid a lot of the
XPCOM overhead in cases where it's not necessary. It's also very hard to
get right because content scripts are not global per-process, so you
have to use singleton techniques like JS modules in order to get the
registration correct.

> Maybe I am just getting used to doing things the hard way :)

I think you have a severe case of Stockholm syndrome...

--BDS

[Benjamin Smedberg]

On 6/20/2011 5:07 AM, Neil wrote:
>
> Sorry, I don't know what you meant when you said "JS event", did you
> mean in a JS module, component, or both?

Probably a component. Why does it matter? Perhaps I should have said
"stored by global JavaScript" and left the details up to the implementer.

--BDS

[johnjbarton]

On 6/27/2011 9:57 AM, Benjamin Smedberg wrote:
> On 6/18/2011 12:44 PM, johnjbarton wrote:
>> On 6/17/2011 10:47 AM, Benjamin Smedberg wrote:
>>> The basic plan is to redesign these APIs so that they take the form of
>>> DOM events fired at the relevant DOM window. They will propagate to
>>> message manager scripts normally.

...

>> If all the new notifications used DOM event APIs directed at
>> JavaScript containers, the architecture of the platform would be
>> clearer. The current platform has other containers for JavaScript such
>> as sandboxes and the mysterious BackStagePass. In fact all JS has to
>> have a natural container associated with its outermost scope. (There
>> is no platform container for JavaScript called "global").
> I don't understand this paragraph. What has any of this got to do with
> sandboxes?
>>
>> Of course part of the clarity may result from struggling with the
>> meaning of this change for the cases not covered. Does it really make
>> sense to send events to a Sandbox? What do we call the BackStagePass
>> things
> This is specifically about sending events through the DOM, and their
> propagation. Sandboxes are not part of the DOM, and cannot receive
> events, so they are irrelevant to the proposal here.

You propose to replace some of the current global XPCOM notifications
with notifications targeted at windows. In my opinion, your proposal is
in the right direction but does not go far enough.

The platform would be more consistent and easier to understand if the
source and destination of events were architecturally defined objects.
Your proposal moves in that direction by shifting some of the
notifications to DOM windows. You noted that some events don't make
sense against DOM windows. I'm suggesting that the remaining events
should make sense against some JS global container and that assigning
the remaining events would make the platform stronger.

jjb

[Neil]

Benjamin Smedberg wrote:

> On 6/20/2011 5:07 AM, Neil wrote:
>
>> Sorry, I don't know what you meant when you said "JS event", did you
>> mean in a JS module, component, or both?
>
> Probably a component. Why does it matter?

Just wondering what the interface would look like, after all, the call
to retrieve the stored messages in the current interface is not ideal.