946971 - Figure out how to e10s-ify observer notifications for content documents

Status: RESOLVED WORKSFORME

(Add-on SDK Graveyard :: General, defect, P2)

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

David, I would really like to chat with you when you have time (next year) about E10S to figure
a best strategy for add-on SDK to make a move.

This specific bug was a followup for the change I laded some time ago to expose DOMContentLoaded, load, pageshow & pagehide events via observer service, which is a lot more convenient (add-on can register
observer on startup and unregister on shutdown) than chasing individual windows that may be in different
states and their nested iframes and keep registering, unregistered various event listeners.

Comment 2

[Dave Townsend [:mossop]]

I contacted Bill, e10s is still middle of the year at earliest and the plan is to review the state of the SDK when we're there. We'll defer any work on it until then.

Comment 3

[Dave Townsend [:mossop]]

What is this bug actually about?

Comment 4

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

(In reply to Dave Townsend [:mossop] from comment #3)
> What is this bug actually about?

I don't think it's relevant at this point. It was requested in the review back when I landed additional observer notifications, as I believe expectation was that somehow these notifications would need to be dispatched in chrome process. At this point it is clear that it's not the case content document  notifications are dispatched in chrome process and SDK code should handle them there via content process & in few cases also send message to chrome process. As of same notifications for chrome documents they are just dispatched in the chrome process as they used to.