[go: nahoru, domu]

Open Bug 1817774 Opened 2 years ago Updated 1 year ago

Investigate proper handling of auto-focus after navigation since bug 1444491 landed

Categories

(Remote Protocol :: Marionette, defect, P1)

Firefox 112
defect
Points:
2

Tracking

(firefox-esr102 unaffected, firefox110 unaffected, firefox111 unaffected, firefox112 wontfix)

ASSIGNED
Tracking Status
firefox-esr102 --- unaffected
firefox110 --- unaffected
firefox111 --- unaffected
firefox112 --- wontfix

People

(Reporter: whimboo, Assigned: whimboo)

References

(Regression, )

Details

(Keywords: regression)

With the changes on bug 1444491 auto-focus related tests are likely to fail after a navigation with Marionette. See bug 1816955 and bug 1817124.

As per temporary fix clients could execute a script to wait for the next animation frame, which would wait for the next page rendering and the auto-focus to be set.

This needs to be discussed and a WebDriver spec issue filed (not sure how BiDi should handle that). I can do the latter later today.

:sefeng, since you are the author of the regressor, bug 1444491, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sefeng)
Keywords: regression

I'm going to have a look.

Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Flags: needinfo?(sefeng)
Summary: Fix handling of auto-focus after navigation after bug 1444491 → Investigate proper handling of auto-focus after navigation since bug 1444491 landed
Severity: -- → S3
Points: --- → 2
Priority: -- → P1

:whimboo is there anything else to do for 112 besides wait for https://github.com/w3c/webdriver/issues/1720 to be fixed?

Flags: needinfo?(hskupin)

Thank you for the reminder. We will have to discuss on Monday in our triage meeting.

Flags: needinfo?(hskupin)
Whiteboard: [webdriver:triage]

Awaiting for a requestAnimationFrame only for Get Active Element wont work given that other commands especially those for element interaction (Perform Actions) would also be affected. And we most likely don't want to workaround for all the cases.

Lets check how the behavior looks like for a navigation where the remote end waits for the readyState to be complete. We should also check how other browsers behave here, and if they might use rAF internally already in case the test passes without the extra call to rAF.

Overall we would need a good reason if the WebDriver classic spec would need to be changed.

I'll do the above mentioned checks over the next days.

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