Open Bug 1803431 Opened 2 years ago Updated 9 months ago

Event handlers not being cleared on browser reload

Categories

(Core :: Networking: WebSockets, defect, P3)

Product:
Core
Component:
Networking: WebSockets
Version:
Firefox 107
Platform:
x86
Windows 10
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: jcmalek, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

test_reload.html
419 bytes, text/html
Details

Steps to reproduce:

Save the following code in test_reload.html:
<html>
<body>
</body>
<script>
let random = Math.random() * 100;
console.error(Creating new websocket: ${random})
let ws = new WebSocket(ws://localhost:8888);
ws.addEventListener("close", () => {
console.error(Closing Web Socket: ${random});
});
ws.addEventListener("open", () => {
console.error(Opening Web Socket: ${random});
});
</script>
</html>

Load it in the browser and hit the "reload" button.

Actual results:

I get the following output on the console:
Closing Web Socket: 43.75825636387588 test_reload.html:9:15
Creating new websocket: 35.564191351568475 test_reload.html:6:13
Opening Web Socket: 35.564191351568475 test_reload.html:12:15

Expected results:

I would have expected the browser refresh to do the following in sequence:
(1) Clear the event handlers (and ideally any other javascript that is still running)
(2) Clear the javascript console.
(3) Execute the new web page and javascript.

Which would have resulted in the following output on the console (which is what I get when I execute the same code in Chrome):
Creating new websocket: 35.564191351568475 test_reload.html:6:13
Opening Web Socket: 35.564191351568475 test_reload.html:12:15

Since I am not aware of any means of doing javascript cleanup on page unload myself, then I believe it currently needs to be the responsibility of the browser. And furthermore, the browser needs to ensure that this cleanup is sufficiently sandboxed so it doesn't bleed into the execution of a completely new instance of a page.

The same problems exists with a hard reload and cache clear then reload.

Attached file test_reload.html —
OS: Unspecified → Windows 10
Hardware: Unspecified → x86

I can't manage to reproduce the issue on my end.
I'm having the same results on both Firefox and Chrome and returning:
Creating new websocket: 52.93271038504764 test_reload (1).html:6:13
Closing Web Socket: 52.93271038504764 test_reload (1).html:9:15

Could you please try if the issue occurs in safe mode. Here is a link that can help you do that: 
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
If the issue still persists, please test it using a new profile, you can find the steps to do that below:
 https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Thanks.

Flags: needinfo?(jcmalek)

(In reply to Hani Yacoub from comment #2)

I can't manage to reproduce the issue on my end.
I'm having the same results on both Firefox and Chrome and returning:
Creating new websocket: 52.93271038504764 test_reload (1).html:6:13
Closing Web Socket: 52.93271038504764 test_reload (1).html:9:15

Could you please try if the issue occurs in safe mode. Here is a link that can help you do that: 
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
If the issue still persists, please test it using a new profile, you can find the steps to do that below:
 https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Thanks.

I get the same behavior in safe mode and after creating a new profile. Several of my co-workers also experience the same bug with Firefox.

Just to double check. Are you sure that you hit the "Reload/refresh" button and then looked at the console and scrolled up in the console if necessary? (The first time the page is loaded you won't see the incorrect logs, only on subsequent reloads)

Flags: needinfo?(jcmalek)

(In reply to jcmalek from comment #3)

(In reply to Hani Yacoub from comment #2)

I can't manage to reproduce the issue on my end.
I'm having the same results on both Firefox and Chrome and returning:
Creating new websocket: 52.93271038504764 test_reload (1).html:6:13
Closing Web Socket: 52.93271038504764 test_reload (1).html:9:15

Could you please try if the issue occurs in safe mode. Here is a link that can help you do that: 
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
If the issue still persists, please test it using a new profile, you can find the steps to do that below:
 https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Thanks.

I get the same behavior in safe mode and after creating a new profile. Several of my co-workers also experience the same bug with Firefox.

Just to double check. Are you sure that you hit the "Reload/refresh" button and then looked at the console and scrolled up in the console if necessary? (The first time the page is loaded you won't see the incorrect logs, only on subsequent reloads)

Actually now that I think about it. I know why you aren't able to reproduce the issue. You have to be running a web socket server at ws://localhost:8888 to accept the connection and then stay alive. Judging by your output, I don't think you started one. My apologies I didn't add it to the instructions. I will update them.

P.S. You need to start a web socket server at ws://localhost:8888 and it has to be accepting connections and stay alive for the duration of this test.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

Do you have a complete demo of this online (including the Web Socket server)?

Flags: needinfo?(jcmalek)

No sorry. I don't have access to an internet facing web server. I am not working for a web page development company.

However, you can download the attached "test_reload.html" to your local host and change the web socket URL to one of the Web Socket echo servers such as "wss://socketsbay.com/wss/v2/1/demo/" and you will be able to reproduce the problem easily.

You just need to:
(1) Change the web socket URL.
(2) Load "test_reload.html" in Firefox.
(3) Hit the "refresh" button.
(4) Look at the console output.

Flags: needinfo?(jcmalek)

I'm not sure whether this bug is a bug of the cache of DOM objects, just WebSockets or the devtools. I move this to WebSockets because the folks could investigate the cause.

Component: DOM: Core & HTML → Networking: WebSockets

I am able to replicate on nightly 111 linux.

The example provided leaves a websocket open, but if we let the page timeout or explicitly close the websocket before the refresh then we do not observe the "close" after dev tools refresh. Seems like something we would want to see if we left a websocket open in previous page run. Kershaw are you able to confirm desired behavior?

Flags: needinfo?(kershaw)

I don't mind seeing a closing socket in dev tools necessarily (I could go either way). However, these web socket events from the old webpage/javascript are actually firing within the newly reloaded webpage/javascript which is definitely a problem since it means that the previously loaded page isn't fully isolated from the newly loaded page.

Blocks: necko-websockets
Severity: -- → S4
Flags: needinfo?(kershaw)
Priority: -- → P3
See Also: → 896666
Whiteboard: [necko-triaged]

Still being effected by this websocket bug in FF.. After 14 years. I'm crying.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: