1166796 - [e10s] sendAsyncMessage() does not work in content process after loading 'about:' page and then loading normal page

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[dw-dev]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150513174244

Steps to reproduce:

I am the developer of the 'Zoom Page' add-on.  Whilst making changes for the next version of Zoom Page, which should avoid the use of CPOW's, I noticed the following problem:

1. Start Nightly 41.0a1.
2. Open a new tab.
3. Load "Google" (or any normal page) into the tab.
4. Then load "about:config" into the same tab.
5. Then load "Google" (or any normal tab) into the same page.
6. sendAsyncMessage() no longer works in the content process!

To demonstrate this, I have built a small addon called 'Demo Bug' (attached) which displays messages when pageshow, resize, click and DOMMOuseScroll events are fired.  For each event, a message is displayed directly in the web page content - and the same message is also sent to the chrome process (using sendAsyncMessage) and displayed in the Bookmark Toolbar.


Actual results:

After completing steps 1-5, sendAsyncMessage() no longer works in the content process!

The messages displayed by the 'Demo Bug' add-on do not remain synchronized between the content process (in the web page content) and the chrome process (in the Bookmark Toolbar).

After step 5:

- messages are still displayed by the content process (in the web page contents), so the events are still being fired, but the message counter has been reset to zero, probably indicating that the frame script has been reloaded.

- messages are no longer received or displayed by the chrome process (in the Bookmark Toolbar), indicating that sendAsyncMessage() is no longer working.


Expected results:

After completing steps 1-5, sendAsyncMessage() should still work in the content process.

The messages displayed by the 'Demo Bug' add-on should remain synchronized between the content process (in the web page content) and the chrome process (in the Bookmark Toolbar).

Comment 1

[dw-dev]

Attachment: DemoBug-1166796-1.0.xpi

Small add-on to clearly demonstrate Bug 1166796.

Comment 2

[Alice0775 White]

(In reply to dw-dev from comment #1)
> Created attachment 8608192 [details]
> DemoBug-1166796-1.0.xpi
> 
> Small add-on to clearly demonstrate Bug 1166796.

It seems to be missing sendAsyncMessage in frame & messageListener in chrome script, no?

Comment 3

[dw-dev]

Attachment: DemoBug-1166796-1.0.xpi

The correct version of 'Demo Bug' add-on.

Comment 4

[dw-dev]

Attachment: DemoBug-1166796-1.1.xpi

Improved version of Demo Bug add-on that adds message container to web page contents only once.

Comment 5

[dw-dev]

(In reply to dw-dev from comment #2)

I have added a new version of the Demo Bug add-on (1.1) and obsoleted the previous versions.

Please install and try out Demo Bug and confirm that you can reproduce the reported problem.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

The problem here is that about:config runs in the parent process while normal web pages run in the content process. When we switch between them, we need to reload everything. That means that frame scripts are reloaded and the <browser> element gets a new message manager. So the listener that was registered with the old message manager is no longer registered with the new message manager.

It looks like all you're trying to do is to load you frame script into every tab and listen to messages from all of them. The easiest way to do that is as follows (in you onLoad handler, maybe):

window.messageManager.loadFrameScript("foo", true); // true means the frame script is loaded in any new tabs that are created as well as the current ones
window.messageManager.addMessageListener("demobug-debugmessage", myListener);

The window message manager gets all messages that go to any of the frame message managers for any of the window's tabs. You can read more about this here:
https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Message_manager_overview

Comment 7

[dw-dev]

Bill, Thanks for the clarification.

In both my "Zoom Page" and "Demo Bug" add-ons, I load the frame script into all tabs using the window message manager, as you have suggested.  However, I add the message listeners for the individual browsers using the browser message managers, rather than just once using the window message manager.  I'm not sure why I added the message listeners this way, since I have read most of the e10s documentation.

I have tried adding the message listener using the window message manager and all of the messages from the frame script are received by the chrome process, even after about:config has been loaded and then replaced by a normal page load.

One potential issue I can see is if the frame script was maintaining global variables across page loads, in which case when browsers are switched between the chrome and content processes, these global variables would be reset.

Is the switching of browsers between the chrome and content processes documented in any of the e10s add-on developer documentation?

As far as I am concerned, this bug can be closed.