|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
58 bytes, text/x-review-board-request
|Details | Review|
Marionette passes an element reference from the content frame script to chrome space in order to gain access to element.mozSetFileArray, so users can set a file for <input type=file>. This functionality is currently implemented in the Marionette:setElementValue message handler in GeckoDriver#sendKeysToElement: https://dxr.mozilla.org/mozilla-central/rev/d4213241bb796fdfa7a5ad4f1989e97b44474364/testing/marionette/driver.js#2208 Bug 1233497 outlaws the use of CPOWs but Marionette currently circumvents this by disabling the throwing via a preference. We should avoid using a CPOW for this.
It looks like constructing File objects in content space is now (somehow) not broken anymore: let file = new File(path); let fs = Array.prototype.slice.call(inputEl.files); fs.push(file); inputEl.mozSetFileArray(fs);
Making this depend on bug 1280947 as it contains some improvements to how we call mozSetFileArray.
Comment on attachment 8786321 [details] Bug 1244425 - Avoid CPOW when setting file array on <input type=file>; https://reviewboard.mozilla.org/r/75306/#review73212
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/6c382a30453a Avoid CPOW when setting file array on <input type=file>; r=automatedtester
Test only changes. Depends on bug 1280947.
All backed out for both for Marionette bustage like https://treeherder.mozilla.org/logviewer.html#?job_id=1571072&repo=mozilla-beta https://hg.mozilla.org/releases/mozilla-aurora/rev/5779143fc12d6a751fedb0b8049d52f4bd10dad9 https://hg.mozilla.org/releases/mozilla-beta/rev/462e604cb5d474ddce189a27eeb0a29242696eee
We are very late in beta now but could still take uplift for 50.
[Tracking Requested - why for this release]: Now that 50 is on the Beta channel, I would not block on this but we should consider fixing this test in Aurora 51. Hi Andreas, David, do we plan to uplift this test fix in Aurora51?
I am pretty sure the reason this failed on uplift was because of a dep which should be in all the way to beta. I will let Andreas run a test to check that we have a clean build/test of beta
I’m unsure about the tracking vs. status flags on this bug: tracking-firefox51: ? status-firefox51: fixed It says it’s been fixed in Firefox 51 but is not tracking. Where do I find out what Firefox version is currently in Aurora/Beta and so on?
Firefox 50 is in Beta at the moment Details can be found in https://wiki.mozilla.org/RapidRelease/Calendar
Un track 51 as it's fixed.
Patch applied cleanly on beta, try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0766b9418af8
Patch seems fine. Requesting uplift again.