Send Keys for file upload elements fails with "WebDriverException: Message: File not found"

RESOLVED FIXED in Firefox 56

Status

P1
normal
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: whimboo, Assigned: whimboo)

Tracking

(Blocks: 1 bug, {regression})

55 Branch
mozilla57
regression
Points:
---

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox55 wontfix, firefox56 fixed, firefox57 fixed)

Details

(Whiteboard: [spec][17/08], URL)

Attachments

(1 attachment)

Originally filed as https://github.com/mozilla/geckodriver/issues/858

Since Firefox 55.0b11 the following Selenium test causes an exception in Marionette when sending keys to a file upload element.

Traceback (most recent call last):
  File "_a/test_selenium.py", line 39, in test_page
    elem.send_keys("/data/Users/henrik/Desktop/screenshot.png")
  File "/Volumes/data/Users/henrik/.venvs/selenium/lib/python2.7/site-packages/selenium/webdriver/remote/webelement.py", line 350, in send_keys
    'value': keys_to_typing(value)})
  File "/Volumes/data/Users/henrik/.venvs/selenium/lib/python2.7/site-packages/selenium/webdriver/remote/webelement.py", line 499, in _execute
    return self._parent.execute(command, params)
  File "/Volumes/data/Users/henrik/.venvs/selenium/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 297, in execute
    self.error_handler.check_response(response)
  File "/Volumes/data/Users/henrik/.venvs/selenium/lib/python2.7/site-packages/selenium/webdriver/remote/errorhandler.py", line 194, in check_response
    raise exception_class(message, screen, stacktrace)
WebDriverException: Message: File not found: /data/Users/henrik/Desktop/screenshot.png

As checked by users this is a regression between Firefox 55.0b10 and 55.0b11.

I checked the same test with a Marionette unit test and it worked just fine. So maybe this is related to an additional preference we set in geckodriver, or something else profile specific.

Changelog between b10 and b11:

https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=e26b1f5d635e&tochange=e5f14b9ae6c4c1e0ff1c430503671289120db203

The only bug which pops out here is bug 1372428. I will check what's wrong here.
It's strange. When I'm trying to further narrow down the range by building locally I don't see this regression and it always fails even for the 55.0b10 changeset. I tried CI builds from TaskCluster but it's the same result. Maybe there is a something special for release builds.
Ok, so when not using any of the default preferences for Marionette in geckoinstance.py I can see the same failure with a Marionette unit test. Going through those prefs I found that the missing `"dom.file.createInChild": True` for geckodriver is causing this problem.

I will have a patch in a moment which adds this pref to both server.js and prefs.rs.
Comment hidden (mozreview-request)

Comment 4

2 years ago
mozreview-review
Comment on attachment 8897461 [details]
Bug 1390486 - Add "dom.file.createInChild" preference to recommended prefs.

https://reviewboard.mozilla.org/r/168760/#review174082

::: testing/geckodriver/CHANGES.md:8
(Diff revision 1)
>  All notable changes to this program is documented in this file.
>  
>  ## Unreleased
>  
>  ### Added
> +- Added preference "dom.file.createInChild" set to true to allow file object creation

Should probably be annotated with backticks (`).

::: testing/geckodriver/CHANGES.md:9
(Diff revision 1)
>  
>  ## Unreleased
>  
>  ### Added
> +- Added preference "dom.file.createInChild" set to true to allow file object creation
> +in content processes.

Also cannot span multiple lines, because this is Markdown.
Attachment #8897461 - Flags: review?(ato) → review+
Comment hidden (mozreview-request)

Comment 6

2 years ago
Pushed by hskupin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e5afed86f2e1
Add "dom.file.createInChild" preference to recommended prefs. r=ato

Comment 7

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/e5afed86f2e1
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox57: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
status-firefox-esr52: --- → unaffected
Keywords: regressionwindow-wanted
Verified with today's Nightly. Can we please get the test-only patch uplifted to beta? Thanks.
Whiteboard: [checkin-needed-beta]
Blocks: 721859
Whiteboard: [checkin-needed-beta] → [spec][17/08][checkin-needed-beta]

Comment 9

a year ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/53842188fe9d
status-firefox56: affected → fixed
Whiteboard: [spec][17/08][checkin-needed-beta] → [spec][17/08]
Andrew, yesterday I have seen bug 1383518 which is interesting because it shows a regression for Firefox 55 at the same time as we experience here for file input types. We simply got it fixed by setting dom.file.createInChild to true, but while reading the other bug I'm not sure if the patch I put up here is the correct way. Maybe it is another regression in Firefox which ships with 55? For further details also see https://github.com/mozilla/geckodriver/issues/858. Thanks.
Flags: needinfo?(bugmail)
Maybe it was a red herring. Looking deeper in code changes for 55 I found bug 1344957. So here this pref was introduced and as mentioned in code changes it is needed to allow the File creation for testing, which we have here. It's still interesting why it regressed for Firefox 55.0b11:

https://github.com/mozilla/geckodriver/issues/858#issuecomment-322260830

Maybe Andrea can shed some light on it.
Flags: needinfo?(bugmail) → needinfo?(amarchesini)
I don't see any particular reason why that range should trigger the failure.
Could it be that the content process was previously marked as FILE_REMOTE_TYPE ?
Flags: needinfo?(amarchesini)
(In reply to Andrea Marchesini [:baku] from comment #12)
> I don't see any particular reason why that range should trigger the failure.

I don't know. Also I was only able to reproduce it for released beta builds but not for any kind of nightly nor self-made build. Not sure if some settings for such kinds of builds have been changed.

> Could it be that the content process was previously marked as
> FILE_REMOTE_TYPE ?

Is there an easy way to get this type? I could have a look by running the test against an old release.
From C++:

  ContentChild* cc = ContentChild::GetSingleton();
  if (cc) {
     printf("Is this a file process? %d\n", cc->GetRemoteType().EqualsLiteral(FILE_REMOTE_TYPE));
  }
Comment hidden (obsolete)
Comment hidden (obsolete)
Before I test the above I noticed that on bug 1344957 Andrea added a line to set this preference in Marionette (driver.js) directly:

https://hg.mozilla.org/mozilla-central/diff/fba648d8582e/testing/marionette/driver.js

This would have been fixed it for both Marionette and geckodriver. But then the follow-up patch on bug 1349859 moved it to geckoinstance.py. As result this preference was only set for Marionette but not geckodriver any longer. We landed this for 55.0 only. For 54 we thought that the patches on bug 1344748 would implicitly fix it, but that didn't happen - as result we didn't uplift and also didn't break Firefox 54.0. 

Interestingly the patch on bug 1349859 landed while 55.0 was on mozilla-aurora and not in beta. So something afterward kept it working until 55.0b11 as the reporter said.

When I tested with 55.0 beta releases even 55.0b1 was not working for me now. Which means the above analysis would be right. So it's a missing uplift for a necessary pref for geckodriver.

With all that I think that we are fine here. Thanks everyone!
You need to log in before you can comment on or make changes to this bug.