Closed Bug 1431116 Opened 6 years ago Closed 3 years ago

Marionette never returns when action sequence causes navigation

Categories

(Remote Protocol :: Marionette, defect, P2)

Version 3
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: ato, Unassigned)

References

(Blocks 2 open bugs, )

Details

(Keywords: hang)

When an action sequence causes a navigation, for examply by clicking
a link, Marionette never returns.

This was originally reported in
https://github.com/mozilla/geckodriver/issues/1063.
This likely happens because due to the unique way we perform
navigations in Marionette.  With commands that are known to cause
navigation, such as WebDriver:{Navigate,Refresh,Back,Forward}, we
send an IPC message to the content frame script instructing it to
begin navigation.  If for whatever reason the content browser suffers
a remoteness change when navigating we flush the pending message’s
queue where we have stored a Marionette:waitForPageLoaded IPC message
that will invoke the “second part” of the navigation algorithm
and return with the original response to the Marionette:get message.

I’ve elaborated on this more in
https://bugzilla.mozilla.org/show_bug.cgi?id=1347458#c4.
This blocks conformance… I think.  Exactly how does the WebDriver
standard say we should handle a navigation attempt in the middle of
an action sequence?
Blocks: webdriver
Flags: needinfo?(simon.m.stewart)
Priority: -- → P2
The spec doesn't say anything explicitly. If the implementation was done at the OS level, the result would be to continue sending keyboard events to the window until the end of typing, and for the next command to queue according to the normal processing model until the load had finished.

OTOH, I can imagine another implementation simply sending keyboard events directly to the underlying browser window abstraction. In this case, if the load happened, I'd expect no more keyboard events to be sent, and for the method to return as normal, though (perhaps) an "unknown error" might be returned.

In either case, the method really should return, even if the spec doesn't spell out exactly what should happen. As it's undefined behaviour, it seems reasonable to either return an error or to curtail keyboard input and return success.
Flags: needinfo?(simon.m.stewart)
Severity: normal → critical
Keywords: hang

I can not reproduce this problem with a recent version of Firefox.

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