1313980 - receive ondisconnect event shortly after chrome.runtime.connectNative

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P1)

Description

[hephaestusx]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20161029030204

Steps to reproduce:

I'm using native messaging to launch a local host app from my web site. After online install my host app, my extension can't communicate with host app.

This issue found in Firefox Nightly 52.0a1(2016-10-30), but can't reproduce in 52.0a1(2016-10-29).


Actual results:

Shortly after chrome.runtime.connectNative in background.js, an onDisconnect event occured and I checked the host app, it is launched and not exited.


Expected results:

Should not receive onDisconnect event in background.js

Comment 1

[Benjamin Smedberg]

hephaestusx, can you provide a testcase? Our automated tests continue to pass, so we need to understand more about what's broken.

Comment 2

[Andrew Swan [:aswan]]

Also, some notes about various things that might be going wrong and how to troubleshoot:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging#Troubleshooting

Comment 3

[Kris Maglione [:kmag]]

Looks like a regression from bug 1299411, based on the regression range, but a testcase would still be helpful.

Comment 4

[hephaestusx]

Benjamin,
Thank you for your quick response.

Here is my code in background.js:

var nativePort = chrome.runtime.connectNative(hostName);
nativePort.onMessage.addListener(function(message) {
//SOME CODE HERE
});
nativePort.onDisconnect.addListener(function() {
//SOME CODE HERE
});
nativePort.postMessage(aHello);  // post a message to host app

In my design, after nativePort.postMessage(aHello), host app will reply a "aHellAck". So I expect the "onMessage" callback function should be called, but actually the "onDisconnect" callback function called. And I checked the host app, it's still alive.

I can't reproduce this issue in Firefox Nightly 52 (2016-10-29) edition, but Firefox Nightly 52 (2016-10-30) no longer work for my code.
I also can't reproduce this issue in Firefox Develop Edition 51.

Comment 5

[hephaestusx]

I got an error in above code when onDisconnect:
nativePort.error: "Error: Could not establish connection. Receiving end does not exist."

Comment 6

[Rob Wu [:robwu]]

That's odd. The code above is similar to the following test, which passes:
http://searchfox.org/mozilla-central/rev/f5c9e9a249637c9abd88754c8963ecb3838475cb/toolkit/components/extensions/test/xpcshell/test_ext_native_messaging.js#144-154

Could you share a complete test case, consisting of:
- native messaging host (e.g. an .exe or .py file).
- native messaging host manifest.
- .reg file that registers the native messaging host manifest.
- background.js (given above?)
- manifest.json
- Exact steps that you followed (e.g. "install native app and load the add-on at about:debugging").
- Are you running multiprocess Firefox (e10s)? (probably yes if you're running Nightly, see about:support)
- OS: Using 32-bit Firefox on 64-bit Windows 7 (based on your bug report)

Comment 7

[hephaestusx]

please try on Windows 7 or above using Firefox Nightly latest version:

1. https://sqsite27.dmz.webex.com
2. Login: 
	user name: Firefox
	password: Mozilla@2016
3. Click: [Start Meeting] or [Meeting Center]->[Meeting Now]
4. Install extension
5. Download native client: Cisco_webex_start.exe and run, we will install a native at: \Users\XXXXXX\AppData\Local\WebEx\NativeMessagingHosts
6. Start meeting
7. End meeting
8. Start/Join meeting again 
	expect: can join meeting
	actual: download native client
	reason: extension call chrome.runtime.connectNative, but will onDisconnect immediately and the native client not be ended.  (please debug extension's background.js)

9. maybe ok for the first time to start/join meeting, and not ok for the second time and so on.

Comment 8

[hephaestusx]

we can find this issue on Windows/Linux/MacOS

Comment 9

[Andrew Swan [:aswan]]

I followed your instructions and saw a bunch of potentially relevant information in the Browser Console.

Initially there was this js exception from your extension:
ReferenceError: extensionHelpDialog is not defined  cwcsf.nativemsg.js:160:1

Then there was a bunch of stderr output from your native application:
stderr output from native app com.webex.meeting: objc[27925]: Class PageNativeObject is implemented in both /Users/andrewswan/Library/Application Support/WebEx Folder/T31_UMC/atconfui.bundle/Contents/MacOS/atconfui and /Users/andrewswan/Library/Application Support/WebEx Folder/T31_UMC/hybridaudio.bundle/Contents/MacOS/hybridaudio. One of the two will be used. Which one is undefined.
stderr output from native app com.webex.meeting: objc[27925]: Class WebViewLoad is implemented in both /Users/andrewswan/Library/Application Support/WebEx Folder/T31_UMC/atconfui.bundle/Contents/MacOS/atconfui and /Users/andrewswan/Library/Application Support/WebEx Folder/T31_UMC/hybridaudio.bundle/Contents/MacOS/hybridaudio. One of the two will be used. Which one is undefined.
stderr output from native app com.webex.meeting: 2016-11-02 23:26:09.744 Meeting Center[27925:11189604] An open requestBody stream is passed to CFReadStreamCreateForStreamedHTTPRequest()
stderr output from native app com.webex.meeting: 2016-11-02 23:26:09.830 Meeting Center[27925:11189685] Stream 0x7863ecc0 is sending an event before being opened
stderr output from native app com.webex.meeting: 2016-11-02 23:26:10.272 Meeting Center[27925:11189604] Failed to connect (m_pRaiseHandButton) outlet from (CPListToolbarMgr) to (CPListToolbarButton): missing setter or instance variable

After this, the native application exited (Firefox responded to the pipe closing)

The extension then apparently re-spawned the native application at which point I was able to join a meeting.  After exiting that meeting I got this error:
Native application tried to send a message of 909193266 bytes, which exceeds the limit of 1048576 bytes.
Note that the number 909193266 in little endian is equivalent to the ascii string "2016".  I'm skeptical that that is a coincidence...

Following that when I try to join a new meeting I see a series of these messages repeating every few seconds with the number before the dash incrementing steadily:
No matching message response handler for 20-0

I'll look into the last issue tomorrow but the other errors suggest that your extension and/or native application aren't working exactly as intended.

Comment 10

[hephaestusx]

Andrew, can you try it on Linux or Windows, for I don't have a Mac machine. On Linux or Windows, the native application not exited even if background.js got a onDisconnect callback.

For MacOS, I'll my colleague check into it.

Comment 11

[hephaestusx]

Note that my code work well on Firefox 51 and Firefox 52 (2016-10-29), but not work on Firefox 52 (2016-10-30) or after.

Comment 12

[Andrew Swan [:aswan]]

I'm sorry I don't have a Linux or Windows machine handy for testing, but on the mac, the native application did exit after the error from comment 9 about the overly large message.  I don't know offhand if it exited by itself or if it was killed by Firefox.

Comment 13

[hephaestusx]

Andrew, I recorded a video about this issue, wish this video will help you debugging it. Thank you.

https://go.webex.com/go/lsr.php?RCID=9fc40026177148db86e5cad8b381af56

Comment 14

[Shihang]

(In reply to Andrew Swan [:aswan] from comment #9)
> I followed your instructions and saw a bunch of potentially relevant
> information in the Browser Console.
> 
> Initially there was this js exception from your extension:
> ReferenceError: extensionHelpDialog is not defined  cwcsf.nativemsg.js:160:1
> 
> Then there was a bunch of stderr output from your native application:
> stderr output from native app com.webex.meeting: objc[27925]: Class
> PageNativeObject is implemented in both
> /Users/andrewswan/Library/Application Support/WebEx
> Folder/T31_UMC/atconfui.bundle/Contents/MacOS/atconfui and
> /Users/andrewswan/Library/Application Support/WebEx
> Folder/T31_UMC/hybridaudio.bundle/Contents/MacOS/hybridaudio. One of the two
> will be used. Which one is undefined.
> stderr output from native app com.webex.meeting: objc[27925]: Class
> WebViewLoad is implemented in both /Users/andrewswan/Library/Application
> Support/WebEx Folder/T31_UMC/atconfui.bundle/Contents/MacOS/atconfui and
> /Users/andrewswan/Library/Application Support/WebEx
> Folder/T31_UMC/hybridaudio.bundle/Contents/MacOS/hybridaudio. One of the two
> will be used. Which one is undefined.
> stderr output from native app com.webex.meeting: 2016-11-02 23:26:09.744
> Meeting Center[27925:11189604] An open requestBody stream is passed to
> CFReadStreamCreateForStreamedHTTPRequest()
> stderr output from native app com.webex.meeting: 2016-11-02 23:26:09.830
> Meeting Center[27925:11189685] Stream 0x7863ecc0 is sending an event before
> being opened
> stderr output from native app com.webex.meeting: 2016-11-02 23:26:10.272
> Meeting Center[27925:11189604] Failed to connect (m_pRaiseHandButton) outlet
> from (CPListToolbarMgr) to (CPListToolbarButton): missing setter or instance
> variable
> 
> After this, the native application exited (Firefox responded to the pipe
> closing)
> 
> The extension then apparently re-spawned the native application at which
> point I was able to join a meeting.  After exiting that meeting I got this
> error:
> Native application tried to send a message of 909193266 bytes, which exceeds
> the limit of 1048576 bytes.
> Note that the number 909193266 in little endian is equivalent to the ascii
> string "2016".  I'm skeptical that that is a coincidence...
> 
> Following that when I try to join a new meeting I see a series of these
> messages repeating every few seconds with the number before the dash
> incrementing steadily:
> No matching message response handler for 20-0
> 
> I'll look into the last issue tomorrow but the other errors suggest that
> your extension and/or native application aren't working exactly as intended.

Hi Andrew, I'm from the same team with hephaestusx, focusing on Mac client. I've repeated steps in Comment#7, and I think that bunch of com.webex.meeting error msgs you mentioned are in step 6, before the real problem comes out in step 8. And com.webex.meeting is not the native app launched by ext, it's not related with this issue.

I've checked native client logs in step 8 when ext re-spawn native app, and quite sure the message sending out by native app is not that long (actually it's a short JSON string '{"message": {"reason": "Hello OK","result": "0"},"message_type": "hello_ack"}').

So, looks like there is something wrong with calculating message length, and ext failed to receive the "hello_ack" message, and take it as no ack, and keeps re-spawning. Actually dozens of native app process launched by ext when search 'webex' in Activity Monitor.

Comment 15

[hephaestusx]

(In reply to Shihang from comment #14)
> (In reply to Andrew Swan [:aswan] from comment #9)
> > I followed your instructions and saw a bunch of potentially relevant
> > information in the Browser Console.
> > 
> > Initially there was this js exception from your extension:
> > ReferenceError: extensionHelpDialog is not defined  cwcsf.nativemsg.js:160:1
> > 
> > Then there was a bunch of stderr output from your native application:
> > stderr output from native app com.webex.meeting: objc[27925]: Class
> > PageNativeObject is implemented in both
> > /Users/andrewswan/Library/Application Support/WebEx
> > Folder/T31_UMC/atconfui.bundle/Contents/MacOS/atconfui and
> > /Users/andrewswan/Library/Application Support/WebEx
> > Folder/T31_UMC/hybridaudio.bundle/Contents/MacOS/hybridaudio. One of the two
> > will be used. Which one is undefined.
> > stderr output from native app com.webex.meeting: objc[27925]: Class
> > WebViewLoad is implemented in both /Users/andrewswan/Library/Application
> > Support/WebEx Folder/T31_UMC/atconfui.bundle/Contents/MacOS/atconfui and
> > /Users/andrewswan/Library/Application Support/WebEx
> > Folder/T31_UMC/hybridaudio.bundle/Contents/MacOS/hybridaudio. One of the two
> > will be used. Which one is undefined.
> > stderr output from native app com.webex.meeting: 2016-11-02 23:26:09.744
> > Meeting Center[27925:11189604] An open requestBody stream is passed to
> > CFReadStreamCreateForStreamedHTTPRequest()
> > stderr output from native app com.webex.meeting: 2016-11-02 23:26:09.830
> > Meeting Center[27925:11189685] Stream 0x7863ecc0 is sending an event before
> > being opened
> > stderr output from native app com.webex.meeting: 2016-11-02 23:26:10.272
> > Meeting Center[27925:11189604] Failed to connect (m_pRaiseHandButton) outlet
> > from (CPListToolbarMgr) to (CPListToolbarButton): missing setter or instance
> > variable
> > 
> > After this, the native application exited (Firefox responded to the pipe
> > closing)
> > 
> > The extension then apparently re-spawned the native application at which
> > point I was able to join a meeting.  After exiting that meeting I got this
> > error:
> > Native application tried to send a message of 909193266 bytes, which exceeds
> > the limit of 1048576 bytes.
> > Note that the number 909193266 in little endian is equivalent to the ascii
> > string "2016".  I'm skeptical that that is a coincidence...
> > 
> > Following that when I try to join a new meeting I see a series of these
> > messages repeating every few seconds with the number before the dash
> > incrementing steadily:
> > No matching message response handler for 20-0
> > 
> > I'll look into the last issue tomorrow but the other errors suggest that
> > your extension and/or native application aren't working exactly as intended.
> 
> Hi Andrew, I'm from the same team with hephaestusx, focusing on Mac client.
> I've repeated steps in Comment#7, and I think that bunch of
> com.webex.meeting error msgs you mentioned are in step 6, before the real
> problem comes out in step 8. And com.webex.meeting is not the native app
> launched by ext, it's not related with this issue.
> 
> I've checked native client logs in step 8 when ext re-spawn native app, and
> quite sure the message sending out by native app is not that long (actually
> it's a short JSON string '{"message": {"reason": "Hello OK","result":
> "0"},"message_type": "hello_ack"}').
> 
> So, looks like there is something wrong with calculating message length, and
> ext failed to receive the "hello_ack" message, and take it as no ack, and
> keeps re-spawning. Actually dozens of native app process launched by ext
> when search 'webex' in Activity Monitor.

Andrew, in our code, we think the native application is not installed if we got onDisconnect event before launch meeting, and we'll try to call connectNative in a few seconds and a new native process launched. And so on...

Comment 16

[Andrew Swan [:aswan]]

Huh, after much searching, it looks like on the subsequent calls to connectNative(), we're getting an error here:
http://searchfox.org/mozilla-central/rev/f5c9e9a249637c9abd88754c8963ecb3838475cb/toolkit/components/extensions/ExtensionUtils.jsm#1522

Specifically, we're getting "No matching message handler".  However, the native application *is* started successfully, we're ending up in a horribly inconsistent state.  I'll try to pick this up again tomorrow.

Comment 17

[Andrew Swan [:aswan]]

Okay, the problem is that the parent process side of connectNative() creates a Port with the frame-specific MM for the background page:
http://searchfox.org/mozilla-central/rev/abf500eeaf1e0b1f417789207a4b9abc4eea8c3e/toolkit/components/extensions/NativeMessaging.jsm#234
This causes MessageChannel to listen on that MM but it doesn't actually have a listener attached for the Extension:Connect message.  This in turn causes the bogus failure of connectNative().

The quick&dirty patch at the end of this comment fixes the immediate problem, I haven't run full tests.  Kris also was concerned about efficiency since this means we'll have to handle all incoming messages from all ports in all child processes.  But I think we may already be doing that:
http://searchfox.org/mozilla-central/rev/f5c9e9a249637c9abd88754c8963ecb3838475cb/toolkit/components/extensions/Extension.jsm#184

ni? to Kris for that specific question but also to help brainstorm overall strategy here.  If I'm right that we're already listening to all port messages on the global frame MM, maybe we just land this patch (with a to-be-written test) and file a follow-up to improve efficiency?  (ie maybe not using MessageChannel for ports other than for the initial connect?)

diff --git a/toolkit/components/extensions/NativeMessaging.jsm b/toolkit/components/extensions/NativeMessaging.jsm
--- a/toolkit/components/extensions/NativeMessaging.jsm
+++ b/toolkit/components/extensions/NativeMessaging.jsm
@@ -226,17 +226,17 @@ this.NativeApp = class extends EventEmit
    *     and receive messages from the port's creator.
    * @param {string} portId A unique internal ID that identifies the port.
    * @param {object} sender The object describing the creator of the connection
    *     request.
    * @param {string} application The name of the native messaging host.
    */
   static onConnectNative(context, messageManager, portId, sender, application) {
     let app = new NativeApp(context, application);
-    let port = new ExtensionUtils.Port(context, messageManager, [messageManager], "", portId, sender, sender);
+    let port = new ExtensionUtils.Port(context, messageManager, [Services.mm], "", portId, sender, sender);
     app.once("disconnect", (what, err) => port.disconnect(err));
 
     /* eslint-disable mozilla/balanced-listeners */
     app.on("message", (what, msg) => port.postMessage(msg));
     /* eslint-enable mozilla/balanced-listeners */
 
     port.registerOnMessage(msg => app.send(msg));
     port.registerOnDisconnect(msg => app.close());

Comment 18

[Rob Wu [:robwu]]

(In reply to Andrew Swan [:aswan] from comment #17)
> Okay, the problem is that the parent process side of connectNative() creates
> a Port with the frame-specific MM for the background page:
> http://searchfox.org/mozilla-central/rev/
> abf500eeaf1e0b1f417789207a4b9abc4eea8c3e/toolkit/components/extensions/
> NativeMessaging.jsm#234
> This causes MessageChannel to listen on that MM but it doesn't actually have
> a listener attached for the Extension:Connect message.  This in turn causes
> the bogus failure of connectNative().

This statement surprises me. This is how I think/expect messaging to work. What part is incorrect?

Calling connectNative in the child [1] triggers a message via the frame MM (context.messageManager).
The parent has set up a listener on the global frame MM (Services.mm) before loading the first extension [2] (without any filters),
so the parent will receive Extension:Connect message on the <browser>'s MM (for bg pages = [3]) and handle the message [4].

Upon receiving the message, onConnectNative creates a port [5] and registers a message listener [6] [7] on the list of MMs given by [5] (currently `[messageManager]`, i.e. the BG <browser>'s MM). These steps happen synchronously, so when the handler for Extension:Connect returns, the MessageChannel has already set up a listener for Extension:Port:PostMessage.

When port.postMessage is called, the message is sent via the frame MM (and received by the <browser>'s MM from the previous paragraph).

So, assuming that the MM don't swap, the child -> parent communication should work.
Another potential reason for receiveMessage not being called is when the filter does not match.
The only filter is the portId ([8]). At construction, the portId is passed around (child [9] to parent [10] for construction of the parent-side Port [11]). postMessage includes the portId [12], so this shows that the filter is not the cause of the dropped message.

(also, all receiveMessage calls/definitions in MessageChannel.jsm are synchronous, so there is no out-of-order message processing)

[1] http://searchfox.org/mozilla-central/rev/008fdd93290c83325de6629a1ae48dc2afaed868/toolkit/components/extensions/ext-c-runtime.js#60
[2] http://searchfox.org/mozilla-central/rev/f5c9e9a249637c9abd88754c8963ecb3838475cb/toolkit/components/extensions/Extension.jsm#171
[3] http://searchfox.org/mozilla-central/rev/008fdd93290c83325de6629a1ae48dc2afaed868/toolkit/components/extensions/ext-backgroundPage.js#74
[4] http://searchfox.org/mozilla-central/rev/f5c9e9a249637c9abd88754c8963ecb3838475cb/toolkit/components/extensions/Extension.jsm#188

[5] http://searchfox.org/mozilla-central/rev/abf500eeaf1e0b1f417789207a4b9abc4eea8c3e/toolkit/components/extensions/NativeMessaging.jsm#234
[6] http://searchfox.org/mozilla-central/rev/abf500eeaf1e0b1f417789207a4b9abc4eea8c3e/toolkit/components/extensions/NativeMessaging.jsm#241
[7] http://searchfox.org/mozilla-central/rev/008fdd93290c83325de6629a1ae48dc2afaed868/toolkit/components/extensions/ExtensionUtils.jsm#1334

[8] http://searchfox.org/mozilla-central/rev/008fdd93290c83325de6629a1ae48dc2afaed868/toolkit/components/extensions/ExtensionUtils.jsm#1241
[9] http://searchfox.org/mozilla-central/rev/f5c9e9a249637c9abd88754c8963ecb3838475cb/toolkit/components/extensions/ExtensionUtils.jsm#1521
[10] http://searchfox.org/mozilla-central/rev/f5c9e9a249637c9abd88754c8963ecb3838475cb/toolkit/components/extensions/Extension.jsm#196
[11] http://searchfox.org/mozilla-central/rev/abf500eeaf1e0b1f417789207a4b9abc4eea8c3e/toolkit/components/extensions/NativeMessaging.jsm#234
[12] http://searchfox.org/mozilla-central/rev/008fdd93290c83325de6629a1ae48dc2afaed868/toolkit/components/extensions/ExtensionUtils.jsm#1354

Comment 19

[evi]

Hi,

We are too seeing this issue in our application.

Everything works perfectly fine until moving away from the page that uses the native app and coming back a second time.
Then we immediately notice that the disconnect is called just after the native port has been setup.

We try to setup a new port, but everytime it fails and we see these error messages:

...
No matching message response handler for 462-0 [MessageChannel.jsm:805]
No matching message response handler for 465-0 [MessageChannel.jsm:805]
No matching message response handler for 468-0 [MessageChannel.jsm:805]
...

Comment 20

[Andrew Swan [:aswan]]

(In reply to Rob Wu [:robwu] from comment #18)
> (In reply to Andrew Swan [:aswan] from comment #17)
> > Okay, the problem is that the parent process side of connectNative() creates
> > a Port with the frame-specific MM for the background page:
> > http://searchfox.org/mozilla-central/rev/
> > abf500eeaf1e0b1f417789207a4b9abc4eea8c3e/toolkit/components/extensions/
> > NativeMessaging.jsm#234
> > This causes MessageChannel to listen on that MM but it doesn't actually have
> > a listener attached for the Extension:Connect message.  This in turn causes
> > the bogus failure of connectNative().
> 
> This statement surprises me. This is how I think/expect messaging to work.
> What part is incorrect?
> 
> Calling connectNative in the child [1] triggers a message via the frame MM
> (context.messageManager).
> The parent has set up a listener on the global frame MM (Services.mm) before
> loading the first extension [2] (without any filters),
> so the parent will receive Extension:Connect message on the <browser>'s MM
> (for bg pages = [3]) and handle the message [4].
> 
> Upon receiving the message, onConnectNative creates a port [5] and registers
> a message listener [6] [7] on the list of MMs given by [5] (currently
> `[messageManager]`, i.e. the BG <browser>'s MM). These steps happen
> synchronously, so when the handler for Extension:Connect returns, the
> MessageChannel has already set up a listener for Extension:Port:PostMessage.

Right but the problem is that the way extension messaging and MessageChannel work, we can't simultaneously listen on an individual frame MM and the global frame MM.  We're ending up in a state that sounds logical: we have a MessageChannel listener on the global frame MM for "Extension:Connect" and a MessageChannel listener on the browser's MM for "...PostMessage".  But down at the MM level everything is a "MessageChannel:Message" with another layer of message routing done at the MessageChannel layer.  So the next time we try to open a native port, the FilteringMessageManager listening to the browser's MM is seeing the "Extension:Connect" message and immediately replying with an error (since it doesn't have a listener for that message, only the FilteringMessageManager attached to the global frame MM does).

Comment 21

[Kris Maglione [:kmag]]

(In reply to Andrew Swan [:aswan] from comment #17)
> The quick&dirty patch at the end of this comment fixes the immediate
> problem, I haven't run full tests.  Kris also was concerned about efficiency
> since this means we'll have to handle all incoming messages from all ports
> in all child processes.  But I think we may already be doing that:
> http://searchfox.org/mozilla-central/rev/
> f5c9e9a249637c9abd88754c8963ecb3838475cb/toolkit/components/extensions/
> Extension.jsm#184

Let's just go for that now.

> ni? to Kris for that specific question but also to help brainstorm overall
> strategy here.  If I'm right that we're already listening to all port
> messages on the global frame MM, maybe we just land this patch (with a
> to-be-written test) and file a follow-up to improve efficiency?  (ie maybe
> not using MessageChannel for ports other than for the initial connect?)

My initial plan with MessageChannel.jsm was to eventually support long-lived,
rather than just single-use, connections using response managers. That would
probably be the best long-term solution for this.

The alternative is to just use plain message managers and add the port ID to
the message names, like we used to do. I don't see any particular reason not
to do that.

Comment 22

[Andrew Swan [:aswan]]

Attachment: Bug 1313980 Avoid listening on browser-specific MM with connectNative()

Review commit: https://reviewboard.mozilla.org/r/92176/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/92176/

Comment 23

[Kris Maglione [:kmag]]

Comment on attachment 8809635 [details]
Bug 1313980 Avoid listening on browser-specific MM with connectNative()

https://reviewboard.mozilla.org/r/92176/#review92234

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a8a331957278
Avoid listening on browser-specific MM with connectNative() r=kmag

Comment 25

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/a8a331957278