WebSocket duplicate packets sent
Categories
(Core :: Networking: WebSockets, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox81 | --- | unaffected |
firefox82 | blocking | verified |
firefox83 | + | verified |
firefox84 | --- | verified |
People
(Reporter: zabrane3, Assigned: kershaw)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [necko-triaged])
Attachments
(3 files, 1 obsolete file)
7.12 MB,
application/octet-stream
|
Details | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
jcristau
:
approval-mozilla-release+
|
Details | Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:82.0) Gecko/20100101 Firefox/82.0
Steps to reproduce:
System: macOS HighSierra v10.13.6 | macOS Catalina v10.15.3|v10.15.7
Send a PDF file of 6995388-bytes using websocket. The javascript app slices the PDF into 1MiB pieces inside a WebWorker, and each chunk was sent using this call: ws.send(Chunk);
Actual results:
The websocket server (listening on: ws://127.0.0.1:8081) is implemented in NodeJS received duplicate packets as you can see:
::: WebSocket server listening on: 8081
{ size: 6995388,
name: 'Domain-Specific_Languages_Made_Easy_v1.pdf',
type: 'application/pdf'}
received: 1048576 bytes | total: 1048576 (1.00 MiB) | sha256: 1fc6527de06c5847a1d9517654cafa527a96e1795b77d4db620a713de129dee0
received: 1048576 bytes | total: 2097152 (2.00 MiB) | sha256: 638fa126dc173ecaabc769313f4c04c8178ef64450d34bb5d31d7ae6c0922d38
received: 1048576 bytes | total: 3145728 (3.00 MiB) | sha256: 638fa126dc173ecaabc769313f4c04c8178ef64450d34bb5d31d7ae6c0922d38
received: 1048576 bytes | total: 4194304 (4.00 MiB) | sha256: 638fa126dc173ecaabc769313f4c04c8178ef64450d34bb5d31d7ae6c0922d38
received: 1048576 bytes | total: 5242880 (5.00 MiB) | sha256: 1d67206b183ee82653380c8533b1d87e23a0397b27eaf2d30b47edecceb40b0f
received: 1048576 bytes | total: 6291456 (6.00 MiB) | sha256: c0b5455a0faea2d40ae99128260d20f30487d4feee0ae7bae9f7423c99c8b494
received: 1048576 bytes | total: 7340032 (7.00 MiB) | sha256: c0b5455a0faea2d40ae99128260d20f30487d4feee0ae7bae9f7423c99c8b494
Furthermore, the server has recieved more data than expected (i.e. 7MiB instead of 6995388-Bytes).
To confirm the bug, a second websocket server was made in Python and experienced the same very issue.
Luckily, we were able to save all network traffic in PCAP format using Wireshark (enclosed).
Expected results:
Packets shouldn't be sent duplicated.
When using Firefox 81.0.2 (or the latest Chrome/Edge/Vivaldi and Safari), all packets are sent only once and everything behaves as expected.
Here is the correct output using Firefox 81.0.2:
{ size: 6995388,
name: 'Domain-Specific_Languages_Made_Easy_v1.pdf',
type: 'application/pdf' }
received: 1048576 bytes | total: 1048576 (1.00 MiB) | sha256: 1fc6527de06c5847a1d9517654cafa527a96e1795b77d4db620a713de129dee0
received: 1048576 bytes | total: 2097152 (2.00 MiB) | sha256: 638fa126dc173ecaabc769313f4c04c8178ef64450d34bb5d31d7ae6c0922d38
received: 1048576 bytes | total: 3145728 (3.00 MiB) | sha256: 1d67206b183ee82653380c8533b1d87e23a0397b27eaf2d30b47edecceb40b0f
received: 1048576 bytes | total: 4194304 (4.00 MiB) | sha256: 0167c13c41ef6cbe0569152c9c1ab40a7d3d913eb98b76c2f52381b9a87bee4f
received: 1048576 bytes | total: 5242880 (5.00 MiB) | sha256: e1b99440608464c11d0a6c38b11aad50fde1a6b4994d344094063a89a023c97e
received: 1048576 bytes | total: 6291456 (6.00 MiB) | sha256: c0b5455a0faea2d40ae99128260d20f30487d4feee0ae7bae9f7423c99c8b494
received: 703932 bytes | total: 6995388 (6.67 MiB) | sha256: cc15c88189b04ffc6abb6e5062ce48499cbb56a54429c0f9a9d3124858e6c9ad
received: 6995388 bytes (6.67 MiB) in 60.61 msec (0:00) | speed: 110.07 MiB/sec
Comment 2•4 years ago
|
||
[Tracking Requested - why for this release]:
Apparent regression in 82 which was just released.
Moving this to the correct component.
Two quick questions:
-
did you intentionally file this as a security-sensitive issue? If so, why do you think this issue is likely to be exploitable? (If possible, we prefer keeping issues on this tracker open so they're easier for people to find and collaborate on)
-
it sounds like you believe this to be a recent regression (between Firefox 81 and 82). As you haven't attached a testcase that would allow us to reproduce, and given that there are literally thousands of commits that landed between those two versions, is it possible for you to find a narrower regression window? We have an automated bisection tool that can help with this - https://mozilla.github.io/mozregression/ . You should be able to run it on the commandline with something like
mozregression --good 81 --bad 82
, and it'll download and run various nightly builds of Firefox (on a new, separate profile) to narrow down when this broke.
Thank you!
1. did you intentionally file this as a security-sensitive issue? If so, why do you think this issue is likely to be exploitable? (If possible, we prefer keeping issues on this tracker open so they're easier for people to find and collaborate on)
I probably checked the security box by mistake. This is my first bug report here, please bear with me.
it sounds like you believe this to be a recent regression (between Firefox 81 and 82). [...]
Yes it's definitely a regression between this two version. I'm gonna play with mozregression --good 81 --bad 82
and report my findings here.
Comment 4•4 years ago
|
||
(In reply to Micka from comment #3)
I probably checked the security box by mistake. This is my first bug report here, please bear with me.
No worries, thank you for clarifying. I'll remove the security-sensitive flag.
it sounds like you believe this to be a recent regression (between Firefox 81 and 82). [...]
Yes it's definitely a regression between this two version. I'm gonna play with
mozregression --good 81 --bad 82
and report my findings here.
That would be really helpful - thank you!
mozregression
seems to be broken. Both nightly build 82.0a1
and 83.0a1
do not suffer from this bug and our test ran smoothly (no packet's duplicated). But when i answer good for 83.0a1, mozregression
doesn't like it:
0:01.59 INFO: Using date 2020-09-21 for release 82
0:02.48 INFO: Using date 2020-08-24 for release 81
0:04.63 INFO: Testing good and bad builds to ensure that they are really good and bad...
0:04.63 INFO: Using local file: /Users/micka/.mozilla/mozregression/persist/2020-08-24--mozilla-central--firefox-82.0a1.en-US.mac.dmg
0:04.63 INFO: Running mozilla-central build for 2020-08-24
0:12.15 INFO: Launching /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpib3ib881/Firefox Nightly.app/Contents/MacOS/firefox
0:12.15 INFO: Application command: /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpib3ib881/Firefox Nightly.app/Contents/MacOS/firefox -foreground -profile /var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpml83wgev.mozrunner
0:12.17 INFO: application_buildid: 20200824215021
0:12.17 INFO: application_changeset: ced8e8e8322c3926439b0b138fe75e44099265a7
0:12.17 INFO: application_name: Firefox
0:12.17 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:12.17 INFO: application_version: 82.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
0:25.32 INFO: Using local file: /Users/micka/.mozilla/mozregression/persist/2020-09-21--mozilla-central--firefox-83.0a1.en-US.mac.dmg
0:25.32 INFO: Running mozilla-central build for 2020-09-21
0:32.98 INFO: Launching /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmp9urtdz_j/Firefox Nightly.app/Contents/MacOS/firefox
0:32.98 INFO: Application command: /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmp9urtdz_j/Firefox Nightly.app/Contents/MacOS/firefox -foreground -profile /var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpxqb8gwx4.mozrunner
0:33.02 INFO: application_buildid: 20200921213612
0:33.02 INFO: application_changeset: a5cdfde00f159276453541049a8cbb5f7043ae2a
0:33.02 INFO: application_name: Firefox
0:33.02 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:33.02 INFO: application_version: 83.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
0:48.13 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect```
Is this of any help to you guys?
Comment 6•4 years ago
|
||
Yes, it helps, though it means we're not quite done yet, sorry! This implies that with a clean, empty profile, our main development branch didn't have this issue at the time that we cut a branch for the 82 release. But clearly your main profile is having this issue.
There are two possibilities I can see. One is that there is something special about your main Firefox profile (a changed option/preference, a feature that's enabled there but not by default, an add-on, or something else) that is tripping this issue. We can exclude this possibility if you try with your "normal" Firefox instance and a new profile - https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles explains how you can create a separate profile to test with. If you can reproduce on the clean profile, then that probably isn't the issue. If you can't reproduce on a clean profile, you can either pass the --profile flag with the right path/name argument to mozregression to make it use a clone of your main profile to do the bisection with, or you could try figuring out what's different between the clean profile and your main profile (add-ons, options you've set, etc).
The other possibility is that mozregression runs against nightly builds, on our main development branch. It's possible that we introduced the regression after the point where we cut the 82 release branch, and then cherry-picked (uplifted) whatever broke this. We do this for things that need to ship ASAP, like security fixes or critical regressions that impact a lot of users. You can exclude this possibility by re-running mozregression and leaving off the --bad
flag entirely. It'll then try to bisect between the 82 branch point and the current state of our development branch (which, if a clean profile in the previous step reproduces the issue, I'd expect to be broken).
Thanks for your swift reply. I created a new profile called TEST-Websocket
on my Firefox 82.0
and i was able to immediately reproduce the issue:
::: WebSocket server listening on: 8081
{
size: 6995388,
name: 'Domain-Specific_Languages_Made_Easy_v1.pdf',
type: 'application/pdf'
}
received: 1048576 bytes | total: 1048576 (1.00 MiB) | sha256: 1fc6527de06c5847a1d9517654cafa527a96e1795b77d4db620a713de129dee0
received: 1048576 bytes | total: 2097152 (2.00 MiB) | sha256: 638fa126dc173ecaabc769313f4c04c8178ef64450d34bb5d31d7ae6c0922d38
received: 1048576 bytes | total: 3145728 (3.00 MiB) | sha256: 638fa126dc173ecaabc769313f4c04c8178ef64450d34bb5d31d7ae6c0922d38
received: 1048576 bytes | total: 4194304 (4.00 MiB) | sha256: 638fa126dc173ecaabc769313f4c04c8178ef64450d34bb5d31d7ae6c0922d38
received: 1048576 bytes | total: 5242880 (5.00 MiB) | sha256: 1d67206b183ee82653380c8533b1d87e23a0397b27eaf2d30b47edecceb40b0f
received: 1048576 bytes | total: 6291456 (6.00 MiB) | sha256: 1d67206b183ee82653380c8533b1d87e23a0397b27eaf2d30b47edecceb40b0f
received: 1048576 bytes | total: 7340032 (7.00 MiB) | sha256: 0167c13c41ef6cbe0569152c9c1ab40a7d3d913eb98b76c2f52381b9a87bee4f
I was able to narrow down the broken commit(s) using your suggestion:
$ mozregression --good 81
[...]
13:48.90 INFO: Downloading build from: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/UoxknK80S1yX53d4lAZ7sg/runs/0/artifacts/public%2Fbuild%2Ftarget.dmg
===== Downloaded 100% =====
13:54.78 INFO: Running autoland build built on 2020-09-11 10:32:39.484000, revision e6c6a83c
14:10.04 INFO: Launching /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpfk0mq8gb/Firefox Nightly.app/Contents/MacOS/firefox
14:10.05 INFO: Application command: /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpfk0mq8gb/Firefox Nightly.app/Contents/MacOS/firefox -foreground -profile /var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmp7c0h_szb.mozrunner
14:10.05 INFO: application_buildid: 20200911101440
14:10.05 INFO: application_changeset: e6c6a83c4de71878ccfa1b3a39d8ace923943695
14:10.05 INFO: application_name: Firefox
14:10.05 INFO: application_repository: https://hg.mozilla.org/integration/autoland
14:10.05 INFO: application_version: 82.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
14:54.37 INFO: Narrowed integration regression window from [36180856, b133e2d6] (22 builds) to [e6c6a83c, b133e2d6] (11 builds) (~3 steps left)
14:54.37 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e6c6a83c4de71878ccfa1b3a39d8ace923943695&tochange=b133e2d673e8ec7719036395a017c0b91ba15937
14:54.37 INFO: Downloading build from: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PxB6AgyeS8mH3omgaaArjg/runs/0/artifacts/public%2Fbuild%2Ftarget.dmg
===== Downloaded 100% =====
14:55.92 INFO: Running autoland build built on 2020-09-11 12:07:37.935000, revision 9dd67fd2
15:11.24 INFO: Launching /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmp158y3ivb/Firefox Nightly.app/Contents/MacOS/firefox
15:11.24 INFO: Application command: /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmp158y3ivb/Firefox Nightly.app/Contents/MacOS/firefox -foreground -profile /var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpdibf1c_v.mozrunner
15:11.25 INFO: application_buildid: 20200911112610
15:11.25 INFO: application_changeset: 9dd67fd23c9eb27ab2d6d0491296e82aa12a6631
15:11.25 INFO: application_name: Firefox
15:11.25 INFO: application_repository: https://hg.mozilla.org/integration/autoland
15:11.25 INFO: application_version: 82.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): 15:15.68 WARNING: Skipping build b76c123c607d: Unable to find build info using the taskcluster route 'gecko.v2.autoland.shippable.revision.b76c123c607df6ea96958e632e8eb65b5628266f.firefox.macosx64-opt'
15:17.11 WARNING: Skipping build a2372b6285d7: Unable to find build info using the taskcluster route 'gecko.v2.autoland.shippable.revision.a2372b6285d7871f7eb6e914583b1113da2038a1.firefox.macosx64-opt'
bad
15:47.82 INFO: Narrowed integration regression window from [e6c6a83c, b133e2d6] (9 builds) to [e6c6a83c, 9dd67fd2] (5 builds) (~2 steps left)
15:47.82 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e6c6a83c4de71878ccfa1b3a39d8ace923943695&tochange=9dd67fd23c9eb27ab2d6d0491296e82aa12a6631
15:47.82 INFO: Using local file: /Users/micka/.mozilla/mozregression/persist/433c4ac7d65a-shippable--autoland--target.dmg (downloaded in background)
15:47.82 INFO: Running autoland build built on 2020-09-11 12:50:23.933000, revision 433c4ac7
15:48.49 WARNING: Skipping build 5012e5d4c2d7: Unable to find build info using the taskcluster route 'gecko.v2.autoland.shippable.revision.5012e5d4c2d7fc7c72c9f1eb1434b94762da15f3.firefox.macosx64-opt'
16:03.49 INFO: Launching /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpgqfp_2y0/Firefox Nightly.app/Contents/MacOS/firefox
16:03.49 INFO: Application command: /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpgqfp_2y0/Firefox Nightly.app/Contents/MacOS/firefox -foreground -profile /var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmp4n3hohob.mozrunner
16:03.50 INFO: application_buildid: 20200911111406
16:03.50 INFO: application_changeset: 433c4ac7d65a7ee98ae406cbc0421185a0c23021
16:03.50 INFO: application_name: Firefox
16:03.50 INFO: application_repository: https://hg.mozilla.org/integration/autoland
16:03.50 INFO: application_version: 82.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
16:43.96 INFO: Narrowed integration regression window from [e6c6a83c, 9dd67fd2] (4 builds) to [433c4ac7, 9dd67fd2] (2 builds) (~1 steps left)
16:43.96 INFO: No more integration revisions, bisection finished.
16:43.96 INFO: Last good revision: 433c4ac7d65a7ee98ae406cbc0421185a0c23021
16:43.96 INFO: First bad revision: 9dd67fd23c9eb27ab2d6d0491296e82aa12a6631
16:43.96 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=433c4ac7d65a7ee98ae406cbc0421185a0c23021&tochange=9dd67fd23c9eb27ab2d6d0491296e82aa12a6631
Please let me know what else i can do.
Assignee | ||
Comment 9•4 years ago
|
||
Thanks for the information.
This looks like caused by bug 1663718, but this could be also fixed by bug 1668851.
Could you try to test again with the latest nightly?
Reporter | ||
Comment 10•4 years ago
|
||
Could you please help me how to test with nightly (i'm new here)? Is there any command to run?
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 11•4 years ago
|
||
(In reply to Micka from comment #10)
Could you please help me how to test with nightly (i'm new here)? Is there any command to run?
Sure. Just download the nightly version from the link below.
https://www.mozilla.org/en-US/firefox/channel/desktop/
Comment 12•4 years ago
|
||
(In reply to Micka from comment #10)
Could you please help me how to test with nightly (i'm new here)? Is there any command to run?
If you like the commandline you could use mozregression given you have it already - mozregression --launch 2020-10-26
will run today's nightly with a throwaway profile that you can use to test this specific bug.
The more visual way of doing it is to simply go to https://nightly.mozilla.org/ and download the most recent nightly dmg, put it somewhere you like, and treat it as another app you installed. This will get very frequent updates. and is effectively the "cutting edge" of our development branch. It'll run using a separate profile from your "normal" Firefox, so it won't touch your regular data etc.
Reporter | ||
Comment 13•4 years ago
|
||
Thanks for the command line tip. I confirm that the bug is still present with this version:
$ mozregression --launch 2020-10-26
0:01.69 INFO: Using local file: /Users/micka/.mozilla/mozregression/persist/2020-10-26--mozilla-central--firefox-84.0a1.en-US.mac.dmg
0:01.69 INFO: Running mozilla-central build for 2020-10-26
0:10.37 INFO: Launching /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpeeyrnqm0/Firefox Nightly.app/Contents/MacOS/firefox
0:10.37 INFO: Application command: /private/var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpeeyrnqm0/Firefox Nightly.app/Contents/MacOS/firefox -foreground -profile /var/folders/y1/nzfql4q9669ffv0s6std2dcr0000gn/T/tmpkj4z8m8k.mozrunner
0:10.39 INFO: application_buildid: 20201026092834
0:10.39 INFO: application_changeset: b1a74943bc51bd3e62ea52242ec5e403ea3760bb
0:10.39 INFO: application_name: Firefox
0:10.39 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:10.39 INFO: application_version: 84.0a1
Assignee | ||
Comment 14•4 years ago
|
||
I might need to ask another favor. Could you provide the minimal test case (both client and server code) to me?
Thanks.
Reporter | ||
Comment 15•4 years ago
|
||
I will try to prepare a minimal test case and report back here
Assignee | ||
Comment 16•4 years ago
|
||
Assignee | ||
Comment 17•4 years ago
|
||
Comment 18•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 19•4 years ago
|
||
A minimal test case is attached here: Bug 1673467
The same bug was encountered by me (Bug 1673621) - I did not find this ticket via the search before opening, you can close the latter as duplicate.
Comment 22•4 years ago
|
||
It's looking like we need to fix this ASAP.
Assignee | ||
Comment 23•4 years ago
|
||
Assignee | ||
Comment 24•4 years ago
|
||
Comment on attachment 9184009 [details]
Bug 1673340 - [For beta] Bug 1673340 - Revert changes done in Bug 1668851, 1663718 and 1497249
Beta/Release Uplift Approval Request
- User impact if declined: Websocket doesn't work properly.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: N/A
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is a backout patch that reverts the websocket code back to a stable version.
- String changes made/needed: N/A
Comment 25•4 years ago
|
||
Comment on attachment 9184009 [details]
Bug 1673340 - [For beta] Bug 1673340 - Revert changes done in Bug 1668851, 1663718 and 1497249
Approved for 83 beta 5, thanks.
Assignee | ||
Comment 26•4 years ago
|
||
Assignee | ||
Comment 27•4 years ago
|
||
Comment on attachment 9184021 [details]
Bug 1673340 - [For release] Revert changes done in Bug 1668851, 1663718 and 1497249
Beta/Release Uplift Approval Request
- User impact if declined: Websocket doesn't work properly.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: N/A
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is a backout patch that reverts websocket code back to a stable version.
- String changes made/needed: N/A
Comment 28•4 years ago
|
||
bugherder |
Comment 29•4 years ago
|
||
bugherder uplift |
Reporter | ||
Comment 30•4 years ago
|
||
Step to reproduce the issue on Firefox 82.0
install deps for NodeJS http+websocket servers
$ npm install ws node-static http
$ cat > node_ws.js
const crypto = require('crypto');
function sha256(data) {
return crypto.createHash('sha256').update(data).digest('hex');
};
// -----------------------------------------------------------------------
// WebSocket server
// -----------------------------------------------------------------------
var port = 8081;
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: port });
console.log('::: WebSocket server listening on:', port);
wss.on('connection', function connection(ws) {
let size = 0;
ws.on('close', function () {
console.log("connection closed...");
});
ws.on('message', function incoming(message) {
size += message.length;
console.log('block received: %d bytes | total: %d | sha256: %s', message.length, size, sha256(message));
});
});
// -----------------------------------------------------------------------
// HTTP server
// -----------------------------------------------------------------------
const static = require('node-static');
const http = require('http');
port = 8080;
var file = new(static.Server)();
http.createServer(function (req, res) {
file.serve(req, res);
}).listen(port);
console.log('::: HTTP server listening on:', port);
console.log('open: http://127.0.0.1:%d/\n', port);
HTML test page
$ cat > index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Firefox 82.0 broken WebSocket test</title>
</head>
<body>
<header>
<h1>Firefox 82.0 vroken WebSocket test</h1>
</header>
<button type="button" id="btn-run">Click Me!</button>
<script>
document.addEventListener('DOMContentLoaded', init);
function init() {
let runBtn = document.getElementById('btn-run')
runBtn.onclick = function() {
let worker = new Worker("index.js");
worker.postMessage('run');
};
}
</script>
</body>
</html>
Web worker test code
$ cat > index.js
function genRandomPayload(){
const size = 6995388;
const max = 64 * 1024;
let buffer = new Uint8Array(size);
let i = 0;
while (i < size){
let sz = Math.min(size - i, max);
let u8 = new Uint8Array(sz);
crypto.getRandomValues(u8);
buffer.set(u8, i);
i += max;
}
return buffer;
}
function genRandomFile() {
return new File([genRandomPayload()], "payload.bin", {type:'application/octet-stream'});
}
function sendFile(file, ws) {
const oneMiB = 1 * 1024 * 1024;
var offset = 0;
while (offset < file.size) {
let blob = file.slice(offset, offset + oneMiB);
let slice = new FileReaderSync().readAsArrayBuffer(blob);
ws.send(slice);
offset += blob.size;
}
ws.close();
}
self.addEventListener('message', (ev) => {
let file = genRandomFile();
let ws = new WebSocket('ws://127.0.0.1:8081');
ws.onopen = function() {
console.log(">>> start uploading: %d bytes", file.size);
sendFile(file, ws);
};
ws.onclose = function(ev) {
if (ev.code != 1005 && ev.code != 1000) console.log('!!! upload failed !!!');
else console.log('>>> upload succeeded');
close();
};
});
Run the HTTP+WebSocket server
$ node node_ws.js
::: WebSocket server listening on: 8081
::: HTTP server listening on: 8080
open: http://127.0.0.1:8080/
Point Firefox 82.0
to http://127.0.0.1:8080/, open the console and click the button.
You'll see duplicated chunks on the NodeJS side in addition to a wrong number (7MiB
) of bytes sent (expected 6995388 bytes
).
If you redo the test with Firefox 81.0.2
, all is good.
Updated•4 years ago
|
Comment 31•4 years ago
|
||
Comment on attachment 9184021 [details]
Bug 1673340 - [For release] Revert changes done in Bug 1668851, 1663718 and 1497249
approved for 82.0.2
Comment 32•4 years ago
|
||
Comment on attachment 9184021 [details]
Bug 1673340 - [For release] Revert changes done in Bug 1668851, 1663718 and 1497249
actually this doesn't apply on m-r, I'll just graft the changes from beta.
Updated•4 years ago
|
Comment 33•4 years ago
|
||
bugherder uplift |
Comment 34•4 years ago
|
||
Reproduced the issue using Firefox 82.0 across platforms (Windows 10 64bit, macOS 10.14 and Ubuntu 18.04) with help from comment 30. Verified that this issues is fixed on Firefox 82.0.2, Latest Nightly 84.0a1 and Latest Beta from treeherder.
Updated•4 years ago
|
Description
•