1123061 - content-document-global-created not fired when loading document in existing window or tab since Fx 36

Status: RESOLVED INVALID

(Firefox :: Extension Compatibility, defect)

Description

[Duncan Loveday]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150117030203

Steps to reproduce:

Working on an addon that registers itself with the nsIObserverService using "addObserver()" method passing "content-document-global-created" as parameter 2, false as parameter 3.


Actual results:

The object passed as parameter 1 did not receive a notification when an existing tab was reloaded or used to navigate to a new document. It did however receive notifications when a new tab was opened.

The behaviour changed between these two builds: On http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-06-03-02-01-mozilla-central/ notifications are received for navigation within an existing tab or when opening a new tab but from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-07-03-02-02-mozilla-central/ and later builds notifications are only received for new tabs being opened. This is not correct.


Expected results:

Notifications for content-document-global-created should be received whenever a new document is opened in an existing tab. I will post a test case in due course unless somebody responds and suggests it is not needed.

Comment 1

[Duncan Loveday]

Attachment: Test addon

Attaching a test addon - bug1123061.xpi

Comment 2

[Duncan Loveday]

Attachment: Test html file

Comment 3

[Duncan Loveday]

Test case now attached, to run

(1) Click on the first attachment and install the test addon
(2) Click on the second attachment. Press the "click me" button and observer the results.

The addon injects an object into the test page, the "click me" then calls a method on the object.

On builds prior to the date I mentioned we see two alerts, one confirming that the object has been set and another showing the result from the call.

On builds on or after the date I mentioned we see only one alert showing that the object has not been set.

There are some console.log messages within the addon code which are informative when viewed from the Browser Toolbox. The addon appears to have registered itself as an observer for content-document-global-created, however notifications are not received when a new document is loaded in an existing tab. They are, however received when opening a new tab.

Comment 4

[Duncan Loveday]

The bug goes away if I disable E10s. Not sure now if the addon needs updating or if there is still an issue. Does the nsIObserverService work across processes ? I guess it should.

Comment 5

[:Gijs (he/him)]

(In reply to Duncan Loveday from comment #4)
> The bug goes away if I disable E10s. Not sure now if the addon needs
> updating or if there is still an issue. Does the nsIObserverService work
> across processes ? I guess it should.

Unfortunately it can't very well, because only objects that can be serialized can be passed between processes, and most of the first parameters for nsIObserver-s "observe" methods can't be serialized. Content document globals are an excellent example of this. :-)


(In reply to Duncan Loveday from comment #0)
> The behaviour changed between these two builds: On
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-06-03-
> 02-01-mozilla-central/ notifications are received for navigation within an
> existing tab or when opening a new tab but from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-07-03-
> 02-02-mozilla-central/ and later builds notifications are only received for
> new tabs being opened. This is not correct.

That's:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2114ef80f6ae&tochange=17e190839086

which is the enabling of e10s...


I expect that you have to create a content script which does the required listening and inserting. You can communicate with the chrome process via message passing. See e.g. https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox for more information, in particular the bits about running code for all content pages:

https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox#Run_a_script_in_all_pages


However, if you're already listening to content globals being created, you probably want to use the child process message manager to listen for the content doc globals instead: https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/The_message_manager#Child_Process_Message_Manager , because if you add a frame script it'll run once for every content page.

The final thing to explain is why you still get notifications for new tabs in e10s: it's because about:newtab is not loaded in the remote process, but in the parent (chrome) process.

I hope this helps explain what's going on. Please consider posting further questions to either https://groups.google.com/forum/#!forum/mozilla.dev.extensions (there are mailing list and newsgroup equivalents for this) or joining #extdev on irc.mozilla.org and asking there.

(I'm also moving this out of the add-on sdk component because the observer service isn't part of the SDK - it's not a "high level API" so it's not of itself e10s-compatible, unfortunately)

Comment 6

[:Gijs (he/him)]

Oh, hm, re-reading the summary of your bug, I do have a last question. Firefox 36 is in beta right now - https://beta.mozilla.org/ - e10s should be turned off by default, and it should work then. Is that right, or do you see a regression on 36 without e10s? Because if so we will need to investigate that quickly...

Comment 7

[Duncan Loveday]

The change in behaviour I see is from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-07-03-02-02-mozilla-central/ which is full of files named firefox-36a1*. I din't change any settings to enable or disable e10s.

Comment 8

[Duncan Loveday]

Thanks for the explanation BTW

Comment 9

[:Gijs (he/him)]

(In reply to Duncan Loveday from comment #7)
> The change in behaviour I see is from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-07-03-
> 02-02-mozilla-central/ which is full of files named firefox-36a1*. I din't
> change any settings to enable or disable e10s.

OK, great. Yes, those are nightly builds - we change whether they have e10s enabled or not on a fairly regular basis.

Comment 10

[Duncan Loveday]

The problem does not occur with the Fx 36.0b1 beta build2 from here http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/36.0b1-candidates/build2

Would you indulge me with one last question - when do you expect e10s to be enabled in a production build - not 36 presumably, will it be 37, 38 etc ? Just need to know how long before I need to tinker with my addon. Thanks.

Comment 11

[:Gijs (he/him)]

(In reply to Duncan Loveday from comment #10)
> The problem does not occur with the Fx 36.0b1 beta build2 from here
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/36.0b1-candidates/
> build2
> 
> Would you indulge me with one last question - when do you expect e10s to be
> enabled in a production build - not 36 presumably, will it be 37, 38 etc ?
> Just need to know how long before I need to tinker with my addon. Thanks.

https://wiki.mozilla.org/Platform/Roadmap#e10s suggests sometime between 42-45. But Aurora (Developer Edition) will likely happen before then (38/39) and it's probably wise to be ready for that... Adapting your add-on won't break it on non-e10s - just make it future-proof. :-)