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)
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.
Reporter | ||
Comment 1•6 years ago
|
||
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.
Depends on: 1345653
Reporter | ||
Comment 2•6 years ago
|
||
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
Depends on: marionette-window-tracking
Flags: needinfo?(simon.m.stewart)
Priority: -- → P2
Reporter | ||
Updated•6 years ago
|
Blocks: webdriver-actions
Comment 3•6 years ago
|
||
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)
Comment 4•3 years ago
|
||
I can not reproduce this problem with a recent version of Firefox.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
Updated•1 year ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•