Closed Bug 1319334 Opened 3 years ago Closed 3 years ago

Intermittent dom/workers/test/serviceworkers/test_bug1151916.html | Test timed out.


(Core :: DOM: Service Workers, defect)

Not set



Tracking Status
firefox51 --- unaffected
firefox52 --- unaffected
firefox53 --- fixed


(Reporter: intermittent-bug-filer, Assigned: catalinb)



(Keywords: intermittent-failure)


(1 file)

This may be another case where we GC a SW instance while waiting for 'statechange' events. I think I managed to reproduce this locally by spamming SpecialPowers.exactGC().
Assignee: nobody → catalin.badea392
After debugging this further, the problem is when the iframe waits for the worker to become "activated".
The test waits for navigator.serviceWorker.ready to resolve then waits for to become 'activated' using the 'statechange' event.

The problem is that we resolve the ready promise before transitioning the registration's state properties.
So we end up doing this:

1. set mActiveWorker to new worker
2. queue registration change ( .waiting -> .active) - TransitionWaitingToActive();
3. queue state change (activating) - TransitionWaitingToActive();
4. SWM->CheckPendingReadyPromises();
At this point, swInfo->mActiveWorker is non-null, thus we will resolve the pending ready promise.
5. Pending ready promise then callback: here the test will add an event listener using
6. The runnable queued at step 2 executes and it will set to registration.waiting.
This will actually clear our reference because, is non-null because it was accessed when
the pending promise's then-callback was executed, while registration.waiting is null.
7. Cycle collect FTW
8. We never get the 'activated' event.
Comment on attachment 8813197 [details] [diff] [review]
Resolve ready promise *after* updating registration.state properties.

Review of attachment 8813197 [details] [diff] [review]:

LGTM, but please write a spec issue and flag it as v1 milestone.  Section 3.4.2 still says:

> 3. If registration’s active worker is null, wait until registration’s active worker changes.
>> Implementers should consider this condition is met when the corresponding registration request gets to the step 6 of Activate algorithm.

This isn't quite right now that step 6 of Activate queues a task to perform the work.
Attachment #8813197 - Flags: review?(bkelly) → review+
Filed - can't set the milestone, though.
Keywords: checkin-needed
Pushed by
Resolve ready promise *after* updating registration.state properties. r=bkelly
Keywords: checkin-needed
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
You need to log in before you can comment on or make changes to this bug.