Closed Bug 1389718 Opened 7 years ago Closed 7 years ago

[OOP] browser.runtime.sendMessage with toProxyScript fails on Windows

Categories

(WebExtensions :: General, defect, P1)

57 Branch
defect

Tracking

(firefox55 unaffected, firefox56 fixed, firefox57 fixed)

RESOLVED FIXED
mozilla57
Tracking Status
firefox55 --- unaffected
firefox56 --- fixed
firefox57 --- fixed

People

(Reporter: catusx, Assigned: mixedpuppy)

References

(Blocks 1 open bug)

Details

(Whiteboard: [proxy])

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce:

1. Extract test-proxy.zip attached and run `web-ext run -f "C:\Program Files\Nightly\firefox.exe"` under the extracted location.
2. Open Menu -> Addons -> Debug Addons
3. Select Debug under extension `Test Proxy`
4. Check the Console output.
5. Additionally, navigate to example.com.

(The extension is basically just registers a proxy script and then calls browser.runtime.sendMessage(..., {toProxyScript: true}) every second. No complicated logic. Please see background.js.)
(Note: You don't need a working proxy server to reproduce this.)


Actual results:

On Windows 10 with Firefox 57.0a1 (2017-08-11) (64-bit), sendMessage fails with `Error: Could not establish connection. Receiving end does not exist.` It gets printed every second.

In addition, when navigating to example.com, it shows fails to connect to proxy error page, indicating the proxy script has not received any message.


Expected results:

sendMessage should succeed and `SUCCESS!` should be printed every second. The proxy script should receive the message sent.

In addition, there is code in proxy script that changes the proxy to DIRECT whenever a message is received. Therefore, when navigating to example.com, it should just show the webpage without trying any proxies.  (Since there is no `console` access in proxy script, I've implemented the logic solely to detect whether the proxy script has received the message or not. Please see proxy.js.)

On Arch Linux with 57.0a1 (2017-08-11) (64-bit), everything works as expected using the same sample extension.

BTW, users of SwitchyOmega, a WebExtension using sendMessage toProxyScript, have reported that the expected behavior is observed on Windows until the 2017-07-10 Nightly Build. It starts to fail in 2017-07-11 Nightly build. I haven't tested this yet, but I hope that such information can save you some trouble bisecting.
Component: Untriaged → WebExtensions: General
Product: Firefox → Toolkit
I confirm this with Firefox 56.0b2
Priority: -- → P2
Whiteboard: [proxy]
QA Whiteboard: investigating
Flags: needinfo?(mixedpuppy)
Please change browser version of bug to 56
I've verified this works fine on osx, but fails on windows.  Given windows is the bulk of users, and this is the only mechanism for communication with the pac file, I think this is a higher priority.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=392ed89ec2730a48d10b1cec741e86a242d28aa3&tochange=a625a2e9b3333a8e76982ea65f077cfded6ac224
Flags: needinfo?(mixedpuppy) → needinfo?(kmaglione+bmo)
Priority: P2 → P1
works on win with remote=false.
Summary: browser.runtime.sendMessage with toProxyScript fails on Windows → [OOP] browser.runtime.sendMessage with toProxyScript fails on Windows
Also confirmed with FF Nightly 57.0a1 (2017-08-23) 64bit on Linux.
> Also confirmed with FF Nightly 57.0a1 (2017-08-23) 64bit on Linux.

Can you pleas try with remote=false?
Assignee: nobody → mixedpuppy
Comment on attachment 8900876 [details]
Bug 1389718 fix receiving a message in proxy sandbox when running OOP,

https://reviewboard.mozilla.org/r/172310/#review177612
Attachment #8900876 - Flags: review?(kmaglione+bmo) → review+
Can you please request beta uplift for this as soon as possible?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(kmaglione+bmo)
Pushed by mixedpuppy@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/6a0fc7e6bd98
fix receiving a message in proxy sandbox when running OOP, r=kmag
Flags: needinfo?(mixedpuppy)
(In reply to Eric Jung [:ericjung] from comment #7)
> > Also confirmed with FF Nightly 57.0a1 (2017-08-23) 64bit on Linux.
> 
> Can you pleas try with remote=false?

The default value of extensions.webextensions.remote is false in my FF.
https://hg.mozilla.org/mozilla-central/rev/6a0fc7e6bd98
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Can we have this fix in FF 56?
Comment on attachment 8900876 [details]
Bug 1389718 fix receiving a message in proxy sandbox when running OOP,

Approval Request Comment
[Feature/Bug causing the regression]: proxy api messaging
[User impact if declined]: windows users (or any if OOP enabled) will be unable to message with PAC scripts
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: no
[Needs manual test from QE? If yes, steps to reproduce]: automated test for this was enabled for remote browsers in this patch, but you can also use the attached xpi to manually test
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: low
[Why is the change risky/not risky?]: a small change with testing enabled
[String changes made/needed]: none
Flags: needinfo?(mixedpuppy)
Attachment #8900876 - Flags: approval-mozilla-beta?
Comment on attachment 8900876 [details]
Bug 1389718 fix receiving a message in proxy sandbox when running OOP,

Fix receiving a message in proxy sandbox when running OOP. Beta56+.
Attachment #8900876 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(In reply to Shane Caraveo (:mixedpuppy) from comment #15)
> [Is this code covered by automated tests?]: yes
> [Has the fix been verified in Nightly?]: no
> [Needs manual test from QE? If yes, steps to reproduce]: automated test for
> this was enabled for remote browsers in this patch, but you can also use the
> attached xpi to manually test

Setting qe-verify- based on the fact that this fix has automated coverage.
Flags: qe-verify-
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.