Closed Bug 1519354 Opened 5 years ago Closed 4 years ago

All commands except those for navigation can hang when unexpected remoteness changes occur

Categories

(Remote Protocol :: Marionette, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: hang)

As seen on bug 1512336 we have a kinda huge problem in Marionette with every command beside the navigation commands. All of them do not use the message command queue, and as such will hang forever if an unexpected remoteness change occurs, eg. something triggered a navigation request.

To at least prevent the infinite hang, a global timeout for each command could help.

But to really fix it we would have to change the way how the parent and the content processes communicate with each other. Maybe this can be all done with the Fission work for Marionette.

The problem with the message command queue is that it’s not very
generic as you need to hard-code every decision to recover when the
first message makes a remoteness change occurs. This is easy with
navigation because we know what has caused the remoteness change
and what to do after to recover. With other commands it might not
be so easy.

Going into the future I don’t think we can expect calls from driver.js
through proxy.js to listener.js to be, or act as if they are,
synchronous. For example I don’t think this.listener.navigate(…)
is the right level of granularity. Specifically for navigation we
should have one IPC message to trigger the navigation, then an event
emitter in the frame script that sends us updates about the state
of the document. Alternatively, if it is possible, use the web
progress listener entirely in chrome space.

Incidentally this approach is similar to what we need to do for the
new remote agent, which I’ve outlined in greater detail in
https://bugzilla.mozilla.org/show_bug.cgi?id=1518468#c3.

Blocks: 1664968

By using the JSWindowActor implementation these hangs should no longer occur.

Depends on: 1660168
No longer depends on: marionette-fission
Blocks: 1532589
No longer depends on: 1660168
Depends on: 1669169
Blocks: 1669326
Blocks: 1673786

For several Fission only test failures it has been proven that enabling actors will solve this problem. Hopefully we can enable actors for all builds later this week.

We have never seen a hang with the JSWindowActor implementation, and given that this is the default architecture in Marionette now I'm going to wontfix this bug.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.