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 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.

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

Verified with today's Nightly. Can we please get the test-only patch uplifted to beta? Thanks.

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.

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.

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 ?

(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)); }

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!