For content -> chrome -> content
--
I generate custom events in the content layer that trigger event handlers in chrome. The chrome code can then access the content data any way necessary.

A load event on the next page would probably suffice for triggering the process of writing that copied data back to content.

For chrome -> chrome
--
Observers. Definitely. Learn them.
http://kb.mozillazine.org/Using_observers

Just have content fire an event and have chrome listen to it. And be very very careful of introducing security holes.

> load event listener (which is the only one to bubble from content to chrome)

AFAIK this isn't true. Some time ago, someone asked in the MZ Extensions forum for a solution to a similar problem, and I was able to create a custom event that bubbled up all the way to the XUL document. I wrote up the steps at http://forums.mozillazine.org/viewtopic.php?p=1005555#1005555

HTH,
Jens

Thanks Jens, Boris... I thought I tried that approach already on the DOMAttrModified event (which is currently defined). It didn't work.

UPDATE: :-( I'm trying the code now, and it's not working on SeaMonkey 1.0b. Basically, content's detecting the event, chrome isn't, and there are no JS errors/warnings in my code.

UPDATE 2: Argh. Thanks, Boris, for pointing out http://lxr.mozilla.org/seamonkey/source/dom/public/idl/events/nsIDOMNSEventTarget.idl . That solves the problem neatly.

For those of you just joining us, the addEventListener call must have a fourth argument (true), to specify your event listener will accept untrusted events as well. This means events from a different domain, for example (all too common in chrome/content situations!) No additional argument is required for removeEventListener, apparently.

I use events too + OBJECT.watch(property, callback)/unwatch(...) JS methods.

I actually have the same need for making some chrome object available to Web pages' script, much like the "sidebar" object is made available. But I'd like my object to know which "window" and "document" it's associated with, and I haven't yet found a way from within the createInstance() of the XPCOM object to determine which "window" causes it to be instantiated. Do you by any chance know how? Thanks!