webworkers don't terminate on closing firefox (ghost windows)




6 years ago
10 months ago


(Reporter: massamino, Unassigned)



24 Branch
Windows 8

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [MemShrink:P2], URL)


(1 attachment)

28.18 KB, application/x-gzip


6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20130514 Firefox/24.0
Build ID: 20130514031031

Steps to reproduce:

I have a web worker that has a setInterval so it keeps running (monitoring system). It uses ajax requests to handle data and display it.

When I add a button to terminate the web worker and after that I close firefox, everything is OK.

If I don't terminate the web worker (what won't happen on the monitoring computer for whatever reason) and close firefox, it will stay in the processes (on windows).

Tested on Windows 8 with Firefox (20/21) and (Nightly 24)

Actual results:

Process keeps running in background

Expected results:

Firefox should have closed completely

Comment 1

6 years ago
I tried onunload, onbeforeunload, onblur for terminating the worker with no luck.


6 years ago
Component: Untriaged → DOM: Workers
Product: Firefox → Core

Comment 2

6 years ago
Do you have a public testcase that demonstrates this behaviour?
Flags: needinfo?(massamino)

Comment 3

6 years ago
I don't have one public. I'll try if I can replicate it with an online testcase.
Flags: needinfo?(massamino)

Comment 4

6 years ago
I'm currently not able to replicate this on a public server with test code.
Maybe I don't need as much cpu time than the real code.

I'm not going to give up on the testcase yet, but I don't really know what triggers it.
The real code loads a json object and checks some parameters to add DOMobjects or alter the contents (data + css(classes)).

I think some code in the worker won't allow it to receive the terminate command. Could it be that when the worker is handling data in a loop the terminate command doesn't have time enough to end the process before firefox handles its last commands?

Comment 5

6 years ago
Is it possible for you to create a limited guest access to your testcase? If yes, send the login/password or the private link to a Mozilla dev.
Flags: needinfo?(massamino)

Comment 6

6 years ago
I'll see what I can do.
Flags: needinfo?(massamino)

Comment 7

6 years ago
Do you have any idea who to contact then?

I have a testcase online, but It needs a little more work to make it act like my offline sample (I think it is because my local iis server and remote data makes it slower so it takes longer for the web worker to get data).

So in the online testcase I open 3 tabs to test. I reload the pages one by one to generate a popup from the web worker (it says the JSON file is not valid on that moment). All pages reload without a problem, but when I close Nightly then it stays in my task manager.


Comment 8

6 years ago
I think you should find some code to delay connections, maybe with setTimeout, to mimic the slowdown.

Is your online testcase public?

Comment 9

6 years ago
Yes it is. Do you want the link?

Comment 10

6 years ago
I tried a slowdown before with a settimeout, but it didn't create the error then. I tried a sample case where I slowed down the ajax request as well, but with no success.

I'll send you the link anyway :)

Comment 11

6 years ago
I tested your testcase, there is clearly a memory leak! No need to close the browser to see the compartments leaking.

I opened 4 tabs with your link and I reload them (by right clicking), I got the error message, then I closed all the tabs.
In about:memory & about:compartements (ghost windows), the tabs are still visible after 5 min and GC/CCing severeal times.

Of course, closing Firefox keeps it loaded in memory.
Blocks: 668871
Ever confirmed: true
Keywords: testcase
Summary: webworkers don't terminate on closing firefox → webworkers don't terminate on closing firefox (ghost windows)
Whiteboard: [MemShrink]

Comment 12

6 years ago
Created attachment 752706 [details]

Comment 13

6 years ago
I'll keep my testcase online for some time so they can test some more.
This sounds pretty bad.  But it's going to be difficult for anyone who doesn't have access to this testcase to fix this bug.

If the testcase is public, can you link to it from here?

Comment 15

6 years ago
I have a link. Here you go: https://bugzilla.oac.be/ServicesTickets.aspx

Comment 16

6 years ago
I can also confirm it has this issue on osx 10.8

Comment 17

6 years ago
I have found that if I handle the error of the JSON.parse, than it doesn't get stuck, so this should be the trigger I guess

in the file /Script/solarwinds.services.webworker.js

var json = null;
if (xmlhttp.responseText) {
try {
json = JSON.parse(xmlhttp.responseText);
} catch(ex) {
json = {};

return callback(json);

Comment 18

6 years ago
hmm, I guess it worked a couple of times, I can still reproduce it with the altered code.
Whiteboard: [MemShrink] → [MemShrink:P2]
-> khuey (where MemShrink and Workers collide)


10 months ago
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.