Although "close" would be an event name more consistent with usual event naming
(like in DOM APIs), I'm choosing "onClosed" here, because it's more in-line with
what debugger transports use (onPacket, onBulkPacket), it's a minimal change
(only LocalDebuggerTransport is affected) and no update to RDP inspector is needed.
MozReview-Commit-ID: B0YnBOOBSNI
--HG--
extra : rebase_source : 793896acf0d35d4de2829dd1e2b5682d9c0130fe
The reason for the intermittent timeouts wasn't actually in the layoutview but
in the computed view instead. It turns out computed view didn't handle
selection change during an ongoing update from previous selection change
correctly. When layout view was moved to the computed view, it caused more
things to happen during selection change which slowed the computed view
updates triggering this race condition.
Whenever selection changed, the previous update was canceled but the
promise that was blocking the inspector-updated event from being emitted
was never resolved nor rejected. This together with the fact that the
layoutview tests didn't properly wait for the initial update after
navigation / reload to finish before they triggered a new upload lead
to the inspector update to hang waiting for the inspector-updated event
and the test to timeout.
These changes fix the issues by rejecting the computed-view updated promise
whenever the update is canceled. This unblocks the inspector-updated event
to be emitted once the selection change has finished and stops the tests
from timing out.
MozReview-Commit-ID: H4cakxkm4vX
--HG--
extra : transplant_source : %B9%DC%08%5D%CB%D8%B4%7B7-%AF%86N2r%F6%F5%92kA
The intermittency is caused by a race condition. When delete is clicked in the
context menu, markupview changes the selection and sends the removeNode request
to the server. The selection change triggers the usual inspector update process
in the client. At the same time, the server removes the node and queues the
mutation triggered by the removal. And here lies the issue.
If the inspector components finish updating BEFORE the removal mutation is
received from the server, the test continues before the breadcrumbs learn
about the deletion and the test fails. If the update is still pending when
the mutation is received, the breadcrumbs have time to update before the
test continues to make assertions about the breadcrumb contents.
The fix here is to make the test to ensure that the breadcrumbs have seen the
deletion before it continues. To enable that, the breadcrumbs need to tell
the world that it has been updated even if the breadcrumbs were just trimmed
and a non-element node was selected that does not trigger the full update
process (early return in the code).
As the inspector update process has been collecting cruft for years and tests
make a lot of assumptions about the emitted events, it's not safe to trigger a
new inspector update in this special case. Therefore, only the
breadcrumbs-updated event is emitted in this special case and the test waits
for that if the deleted node is still present in the breadcrumbs.
MozReview-Commit-ID: AjC6k6SzLCu
--HG--
extra : rebase_source : 64260d447973c352a5df064bc7f5630b6b92fe81
