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

Status: NEW

(Core :: DOM: Workers, defect, P5)

Description

[Massamino]

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

[Massamino]

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

Comment 2

[Josh Matthews [:jdm]]

Do you have a public testcase that demonstrates this behaviour?

Comment 3

[Massamino]

I don't have one public. I'll try if I can replicate it with an online testcase.

Comment 4

[Massamino]

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

[Loic]

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.

Comment 6

[Massamino]

I'll see what I can do.

Comment 7

[Massamino]

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.

Tnx

Comment 8

[Loic]

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

Is your online testcase public?

Comment 9

[Massamino]

Yes it is. Do you want the link?

Comment 10

[Massamino]

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

[Loic]

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

STR:
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.

Comment 12

[Loic]

Attachment: memory-report.json.gz

Comment 13

[Massamino]

I'll keep my testcase online for some time so they can test some more.

Comment 14

[Justin Lebar (not reading bugmail)]

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

[Massamino]

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

Comment 16

[Massamino]

I can also confirm it has this issue on osx 10.8

Comment 17

[Massamino]

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

[Massamino]

hmm, I guess it worked a couple of times, I can still reproduce it with the altered code.

Comment 19

[Ben Turner (not reading bugmail, use the needinfo flag!)]

-> khuey (where MemShrink and Workers collide)