Closed Bug 1776190 Opened 2 years ago Closed 8 months ago

Modifier keys are no longer reset when getting sent multiple times for "WebDriver:ElementSendKeys"


(Remote Protocol :: Marionette, defect, P1)

Firefox 99


(firefox-esr102 wontfix, firefox112 wontfix, firefox113 wontfix, firefox114 fixed)

114 Branch
Tracking Status
firefox-esr102 --- wontfix
firefox112 --- wontfix
firefox113 --- wontfix
firefox114 --- fixed


(Reporter: michael.ketting, Assigned: whimboo)




(Keywords: regression, Whiteboard: [webdriver:m7][webdriver:relnote])


(2 files)

Steps to reproduce:

Use OpenQA.Selenium.IWebElement.GetAttribute("value") to retrieve the value of an input element.

Used gecko driver version: 0.30.
Please note, that this is NOT a regression in gecko but in Firefox. This call worked in Firefox v97 and works in Chrome and Edge. To me, this implies a regrssion in Firefox v98.

The issue can be reproduced in Firefox v99, v100, and the current v101 as well.

This defect blocks automated web testing with Firefox.

Actual results:

The web driver call returns an empty string.

Expected results:

The current value of the input element is returned.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Startup and Profile System' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
Component: Startup and Profile System → General
Product: Toolkit → Firefox
Summary: Cannot retrieve input.value via geckodriver starting with Firefox 98 → Cannot retrieve input.value via geckodriver starting with Firefox 99
Version: Firefox 98 → Firefox 99

Correction: the first affected version is Firefox v99. The issue can be reproduced both with the older geckodriver v0.30 (used with Firefox v98) and geckodriver v0.31 (normally used with Firefox v99). This still implies that geckodriver is not at fault.

OS: Unspecified → Windows
Hardware: Unspecified → Desktop
Component: General → geckodriver
Product: Firefox → Testing

Would you mind attaching a trace log of your problem? Also a small complete test case would be great. We have automated tests which didn't show any problem yet so it would be good to know what exactly is causing it for you. Thanks.

Flags: needinfo?(michael.ketting)

Hi Henrik,
will do. Unfortunately, it turns out that it's caused by something in the Selenium/Coypu/project-specific-workarounds stack. Doesn't change the fact that the only changed variable is the Firefox version, but getting to the most minimal repro sample just become more...involved.

Flags: needinfo?(michael.ketting)

Perhaps can help then? It should allow us to see exactly what firefox change it really is. You can just add the regression range to the bug.

Flags: needinfo?(michael.ketting)

No reply from the reporter for more than 2 weeks. I'm going to close this bug as incomplete but I'm happy to reopen in case a trace log can be provided which shows this issue.

Closed: 1 year ago
Resolution: --- → INCOMPLETE


we've now been able to reproduce this in an isolated scenario (and also found a workaround):


In short, the problem appears when you use SendKeys to clear the input field and in the same roundtrip, send the new data, too. Once you split this into separate operations, the bug disappears. This happens first with Firefox v99.

Flags: needinfo?(michael.ketting)

Thank you for the update! So basically I can see bug 1757636 and bug 1686666 landed for this Firefox release, which might have triggered that. Could I ask you to run the following Firefox Nightly builds to check when the regression actually happened?

Bug 1757636


Bug 1686666


Does it regress between those two possible landings?

Flags: needinfo?(michael.ketting)

I'm actually able to reproduce it now with the following Marionette test:

        self.marionette.navigate(inline("""<input type="text" value="foo">"""))
        elem = self.marionette.find_element(By.TAG_NAME, "input")
        elem.send_keys(Keys.META + 'a' + Keys.META + Keys.DELETE + "cheese")
        self.assertEqual(elem.get_property("value"), "cheese")

I'll run mozregression to find the exact range.

Ever confirmed: true
Flags: needinfo?(michael.ketting)
Resolution: INCOMPLETE → ---

The regression range is:

Bug 1686666 is clearly in range here so I would suspect that it triggered this regression. James can you please have a look?

Component: geckodriver → Marionette
Flags: needinfo?(james)
Keywords: regression
OS: Windows → All
Product: Testing → Remote Protocol
Regressed by: 1686666
Hardware: Desktop → All

I had a quick look and the problem seems to be actually in this line:

As it can be seen the modifier key is always set to true even if it is send multiple times. Its state should actually get negated.

Summary: Cannot retrieve input.value via geckodriver starting with Firefox 99 → Modifier keys are not reset when getting sent multiple times for "WebDriver:ElementSendKeys"

As Julian pointed out on Matrix we actually should only reset the modifier keys after the full string has been dispatched. As such the current behavior actually makes sense and would be compliant with the WebDriver classic specification.

We do not have specific WebDriver classic tests for this scenario yet, which we should get added.

I'm leaving the regression and needinfo for now for a final feedback from James.

Actually there is Keys.NULL which would have to be used to reset the modifier keys. But sadly we do not support this as well yet (see bug 1494661). Per se this is not a regression and as such I'm removing the flags now.

We will discuss in next week's triage meeting.

Depends on: 1686666
Flags: needinfo?(james)
Keywords: regression
No longer regressed by: 1686666
See Also: → 1494661
Summary: Modifier keys are not reset when getting sent multiple times for "WebDriver:ElementSendKeys" → Modifier keys are no longer reset when getting sent multiple times for "WebDriver:ElementSendKeys"
Whiteboard: [webdriver:triage]

I run the following test as Selenium test with Chrome and it passes while Firefox fails:

    driver.get(inline('<input id="input" type="text" value="foo">'))
    elem = driver.find_element(By.ID, "input")
    elem.send_keys(Keys.META + 'a' + Keys.META + Keys.DELETE + "cheese")
    assert elem.get_property("value") == 'cheese'

Thanks, Henrik, for finding the root cause! Am I correct in my interpretation that you have all the infos you need right now?

As discussed on Matrix today we will actually handle that bug as regression and revert the behavior even it will be non Webdriver spec compliant. Reason is because Chrome shows the same behavior.

I filed for a discussion in the W3C group what we actually should do.

Assignee: nobody → hskupin
No longer depends on: 1686666
Keywords: regression
Priority: -- → P1
Regressed by: 1686666
Whiteboard: [webdriver:triage]
Attachment #9328134 - Attachment description: Bug 1776190 - [marionette] Allow a modifier key to be reset when sending it again within the same command.. → Bug 1776190 - [marionette] Allow a modifier key to be reset when sending it again within the same command.
Pushed by
[wdspec] Move module and modifier_key fixture to global supports folder. r=webdriver-reviewers,jdescottes
[marionette] Allow a modifier key to be reset when sending it again within the same command. r=webdriver-reviewers,jdescottes
Created web-platform-tests PR for changes under testing/web-platform/tests
Closed: 1 year ago8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 114 Branch

The patch landed in nightly and beta is affected.
:whimboo, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox113 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(hskupin)

Just a single report since the release of Firefox 99. We do not see a reason for an uplift. As such lets get this fix ride the trains.

Flags: needinfo?(hskupin)
Upstream PR merged by jgraham
Duplicate of this bug: 1824345
Points: --- → 2
Whiteboard: [webdriver:m7][webdriver:relnote]
You need to log in before you can comment on or make changes to this bug.