If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

In case of remoteness changes the driver has to re-establish the communication with the framescript and not hang

NEW
Unassigned

Status

Testing
Marionette
P3
normal
6 months ago
10 days ago

People

(Reporter: whimboo, Unassigned)

Tracking

(Depends on: 1 bug)

Version 3
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 months ago
As seen at least for bug 1347456 from Treeherder but also noticed locally a couple of times, we have hangs in the driver when a remoteness change occurred and the communiction with the framescript happened via the dispatcher while the command hasn't queued in pendingCommands.

This is clearly a serious issue and can happen at various times when a command triggers a page load and Marionette doesn't wait for it to be finished. Please note that right now we only wait for that in get(), goBack(), and goForward(). But nowhere else.

I will try to setup a testcase for that which actually might not be that hard.
(Reporter)

Updated

6 months ago
Blocks: 1347112
(Reporter)

Comment 1

6 months ago
Trying to reproduce with current code is hard, but if we exclude a page load for file:// urls in navigate.js, the following snippet will promptly cause a hang all the times:

    def test(self):
        self.marionette.navigate("file:///")
        self.marionette.get_url()

The call to get_url() never returns, and Marionette runs into the socket timeout.
(Reporter)

Comment 2

6 months ago
Btw. there seem to be events we might be able to use to get informed about a remoteness change. Those are BeforeTabRemotenessChange and TabRemotenessChange.

Maybe we should listen to the events and re-send the message to the listener once the remoteness change has been completed.
(Reporter)

Updated

5 months ago
Blocks: 1360466
(Reporter)

Comment 3

5 months ago
Something which also helps here is to ensure that every possible navigation request is clearly routed through the loadListener. But this is something we cannot always expect, eg. if the user presses enter on a submit button. In such a case a new page is most likely to get loaded, and the following command will fail to execute due to a possible remoteness change.
Blocks: 1362744
(Reporter)

Updated

5 months ago
No longer blocks: 1362744
Priority: -- → P3
(Reporter)

Updated

10 days ago
Depends on: 1311041
You need to log in before you can comment on or make changes to this bug.