1527978 - postMessage spamming limit handling is broken

Status: RESOLVED FIXED

(Core :: DOM: Workers, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1426467#c75

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Attachment: postmessage_spam.diff

In practice this should be enough.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Restating (for my own future benefit):

• Bug 1426467 introduced WorkerDebuggeeRunnable which makes WorkerRunnable::DispatchInternal use WorkerPrivate::DispatchDebuggeeToMainThread instead of WorkerPrivate::DispatchToMainThread.
• WorkerPrivate::DispatchDebuggeeToMainThread does mMainThreadDebuggeeEventTarget->Dispatch
• So we need to invoke AwaitIdle on mMainThreadDebuggeeEventTarget instead of mMainThreadEventTarget.

And the meta of bug 1426467 was that there was a broken hacky mechanism where postMessage and error runnables (MessageEvent, ReportErrorRunnable, ReportGenericErrorRunnable) would check if they weren't actually supposed to run when it was their turn to run, instead putting themselves on an ad hoc queue that would completely mess up ordering and cause debugger nightmares when single-stepping. So the solution was the new event target for these content-visible runnables that the debugger likes to be able to stop. (Whereas things like fetch/XHR don't interact with the owning page directly and so their runnables can continue operating even if the owning window is being single-stepped.)

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(FWIW, this bug applies to worker.postMessage only. MessagePort.postMessage and BroadcastChannel.postMessage use different mechanisms)

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/eb06f238c16a
bring back the old behavior of worker's postMessage spam limit, r=baku

Comment 5

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/eb06f238c16a