Open Bug 758042 Opened 12 years ago Updated 2 years ago

Worker messages received drifted from the order being sent

Categories

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

12 Branch
x86
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: rex, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120423122624

Steps to reproduce:

Ubuntu 12.04
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0

MainUI.html
========================================
<html>
<head>
<script type="text/javascript">
    function AreaController(areaId) {
        var area = null;
        this.append = function(line) {
            if (area == null) {
                area = document.getElementById(areaId);
            }
            area.value += (line + "\n");
        };
        this.clear = function() {
            if (area == null) {
                area = document.getElementById(areaId);
            }
            area.value = "";
        };
    }

    leftArea = new AreaController("leftText");

    lastTimestamp = "0";

    worker = new Worker("WebWorker.js");
    worker.onmessage = function(event) {
        var msg = event.data;

        var timestamp = msg.split(":")[1];
        if (lastTimestamp >= timestamp) {
            msg += " <<<";
        } else {
            lastTimestamp = timestamp;
        }

        leftArea.append(msg);
    }
</script>
</head>
<body>
	<textarea id="leftText" rows="30" cols="50" readonly="readonly"></textarea>
	<br />
	<input type="button" value="Clear" onClick="leftArea.clear()">
</body>
</html>

WebWorker.js
========================================
setInterval(function() {
    msg = "WebWorker:" + new Date().getTime();
    postMessage(msg);
}, 1111);



Actual results:

1, Within a couple of minutes of running MainUI.html, 
2, Firefox pops up a warning dialog (see below), 
3, and a message arrives in wrong order of being sent (see "<<<" marked line below).

========================================
Warning: Unresponsive script

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: file:///<...>/MainUI.html:28


========================================
WebWorker:1337810763261
WebWorker:1337810764372
WebWorker:1337810766594
WebWorker:1337810767705
WebWorker:1337810768816
WebWorker:1337810769926
WebWorker:1337810771038
WebWorker:1337810772150
WebWorker:1337810773260
WebWorker:1337810774371
WebWorker:1337810775482
WebWorker:1337810765483 <<<
WebWorker:1337810776593
WebWorker:1337810777704



Expected results:

The marked message should be 9 lines above its current position as its time stamp suggests.
Summary: Worker messages arrive drifted from order being sent → Worker messages received drifted from the order being sent
I think this is just the interaction with the slow script dialog.  The message being run when the slow script dialog fires will be delayed until the dialog is closed.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Hi Kyle, I still think this is a wrong behavior and I stated my reasoning below. Hope to see your input soon.

I am not sure if the semantics of "messages should be received on the other side in the order of being sent by postMessage()" is defined in the web worker's spec. I'd guess that most of programmers will expect that in normal situations. When it comes to the slowness I'd expect some adjustments like:

1) If a message is slow, all messages after it should wait.

2) If a message is slow and a slow script dialog is being displayed, all messages after it should still wait until either of followings:

2.1) User clicked on Stop script: the message should be discarded, rest of messages continue as usual. This may break the program but user is aware of it.

2.2) User clicked on Continue: then all messages continue to wait until the the message finally arrives or case 2.1 happens on another dialog (I am assuming a slow dialog will display again repeatedly at a certain interval).
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Verified that it is still happening in version 13.0.1. However it is less frequent than in version 12. I had to wait for a couple of minutes to see it happen.

Version info: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0.1
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.