Content to Chrome Event Handling: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 31: Line 31:


- Should registerRemoteEventListener have also sync-or-async parameter?
- Should registerRemoteEventListener have also sync-or-async parameter?
- When adding a new tab, it must be able add event listeners early enough so that no events coming from content process is missed. (For example the load event from about:blank ContentViewer.)

Revision as of 05:36, 11 December 2009

In electrolysis (and also in general), event propagation should not automatically happen between content and chrome. This is because forwarding unnecessary events between content and chrome causes lots of extra IPC traffic, and the events will not provide access to the content nodes directly (in most cases).

Instead, there should be two methods for noticing and handling events in chrome:

xulbrowser.registerEventListener("load", function(e) {
  // handler
  // e.target will be a JPW
}, true);
// true means "handle event synchronously", false means "handle event asynchronously)

xulbrowser.registerRemoteEventListener("load", "resource:///browser-contenthandlers.js", "functionName", function(json) {
  // resource:///browser-contenthandlers.js is loaded as a JS module within
  // the content process. `functionName` is looked up within this module and
  // called with the DOM event.
  // functionName returns something which can be serialized as JSON
  // this function gets the JSON and does something with it.
});

These APIs should be provided and behave roughly identically whether or not the xul:browser is actually remote or local. Under no circumstances will .addEventListener in the XUL document receive DOM events which originate directly from content.


Few comments (by Olli)

- registerEventListener needs a parameter for the event phase, so does registerRemoteEventListener.

- I'm not sure why .addEventListener shouldn't receive events which originate from content. I'd like to use the normal DOM event dispatch for all events. <browser> is usually hidden somewhere in XBL and in <tabbrowser> case there are several <browser> elements. It is handy to have just one listener for all of them. Currently E10s FrameLoader has activateFrameEvent method, which activates event forwarding from content process to chrome process. Even that isn't very good since whenever a new tab is added, activateFrameEvent needs to be called for all the needed events. Or do we just add some code to <tabbrowser> which keeps a list of all the listeners which need to be added to a <browser> when new tab is added?

- Should registerRemoteEventListener have also sync-or-async parameter?

- When adding a new tab, it must be able add event listeners early enough so that no events coming from content process is missed. (For example the load event from about:blank ContentViewer.)