Closed Bug 1390486 Opened 6 years ago Closed 6 years ago

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


(Testing :: geckodriver, defect, P1)

55 Branch


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

Tracking Status
firefox-esr52 --- unaffected
firefox55 --- wontfix
firefox56 --- fixed
firefox57 --- fixed


(Reporter: whimboo, Assigned: whimboo)


(Blocks 1 open bug, )


(Keywords: regression, Whiteboard: [spec][17/08])


(1 file)

Originally filed as

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/", line 39, in test_page
  File "/Volumes/data/Users/henrik/.venvs/selenium/lib/python2.7/site-packages/selenium/webdriver/remote/", 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/", 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/", line 297, in execute
  File "/Volumes/data/Users/henrik/.venvs/selenium/lib/python2.7/site-packages/selenium/webdriver/remote/", 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:

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 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
Comment on attachment 8897461 [details]
Bug 1390486 - Add "dom.file.createInChild" preference to recommended prefs.

::: testing/geckodriver/
(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/
(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+
Pushed by
Add "dom.file.createInChild" preference to recommended prefs. r=ato
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Verified with today's Nightly. Can we please get the test-only patch uplifted to beta? Thanks.
Whiteboard: [checkin-needed-beta]
Blocks: webdriver
Whiteboard: [checkin-needed-beta] → [spec][17/08][checkin-needed-beta]
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 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:

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

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));
Before I test the above I noticed that on bug 1344957 Andrea added a line to set this preference in Marionette (driver.js) directly:

This would have been fixed it for both Marionette and geckodriver. But then the follow-up patch on bug 1349859 moved it to 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.