Open Bug 1673478 Opened 4 years ago Updated 2 months ago

Attempt to resume or retry "WebDriver:ExecuteScript" and "WebDriver:ExecuteAsyncScript" commands aborted by MarionetteFrameActor

Categories

(Remote Protocol :: Marionette, task, P3)

Default
task

Tracking

(Not tracked)

People

(Reporter: jdescottes, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [webdriver:backlog])

See https://bugzilla.mozilla.org/show_bug.cgi?id=1673345#c0 for more context.

If the executeScript query fails due to an AbortError, we will assume the command was successful and will silently return null. The goal of this bug is to try to better track the completion of the command so that we can decide if it needs to be retried with the next JSWindowActor pair.

Summary: Attempt to resume or retry executeScript command aborted by MarionetteFrameActor → Attempt to resume or retry "WebDriver:ExecuteScript" and "WebDriveR: command aborted by MarionetteFrameActor

Note that in this weeks TPAC sessions this will be discussed. I will update the bug later this week.

Summary: Attempt to resume or retry "WebDriver:ExecuteScript" and "WebDriveR: command aborted by MarionetteFrameActor → Attempt to resume or retry "WebDriver:ExecuteScript" and "WebDriver:ExecuteAsyncScript" commands aborted by MarionetteFrameActor
Whiteboard: [webdriver:backlog]
Blocks: 1761634

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #1)

Note that in this weeks TPAC sessions this will be discussed. I will update the bug later this week.

Looks like I forgot to update the bug. The meeting notes regarding this topic can be found at:
https://www.w3.org/2020/10/27-webdriver-minutes.html#t05

Given the notes we should raise an error in case of both commands but it looks like that we would need a WebDriver classic spec update first.

James, I assume it should be handled similar to suddenly appearing user prompts and erroring out with a javascript error?

Flags: needinfo?(james)

Yes, that seems correct. I think ECMAScript just basically says "agents can stop making forward progress", so we might need to add some text to WebDriver to handle this explicitly.

Flags: needinfo?(james)
Product: Testing → Remote Protocol

Maybe we should not retry to evaluate scripts given that we don't know what exactly they are doing. It might be better to offload a retry attempt to the client by using a dedicated error type indicating that the navigable got destroyed.

Whatever the GitHub issue should be taken care of. Lets discuss in next week's triage meeting how to continue.

Whiteboard: [webdriver:backlog] → [webdriver:backlog][webdriver:triage]
No longer blocks: 1761634

We discussed today in the triage meeting.

Basically we should have the same behavior as Chrome to offer a good cross-browser experience. It would be good to have some wdspec test cases for navigation (cross-origin, initial about:blank) and script execution and compare it between Firefox and Chrome. But in general we should try to avoid any major changes which would leave clients broken because they have their own checks running for navigation finished.

If it turns out that there are issues with JSWindowActor maybe some of the commands have to be routed via the JSProcessActors so that they better survive and we could get results still send to the parent process.

Right not we return None if the JSWindowActor is gone. We could think about a pref to change that behavior in case we could return a dedicated error type per WebDriver classic specification.

Whiteboard: [webdriver:backlog][webdriver:triage] → [webdriver:backlog]
You need to log in before you can comment on or make changes to this bug.