182 bytes, text/html
Created attachment 8785419 [details] fileupload.html: Test file that demonstrates the file selection behavior. User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20160822004020 Steps to reproduce: * In Pages 5.6.2 on the Mac, create and save a test Pages document. * In Pages, select File > Advanced > Change file type > Package * Resave the document. * In Firefox 48 go to a web page that has an input type="file" for a file upload. * Try to select the saved Pages document for upload. Actual results: The interior contents of the document are shown, since it uses a directory format on disk for the "Package" file type selected in step 2. Expected results: It would allow selecting and uploading the Pages document that is in this "package" format and upload. Chrome 52 and Safari 9 on the Mac work in this way.
I guess it's something related to webkitdirectory/directory, but the testcase doesn't have either webkitdirectory nor directory... maybe Chrome and Safari do extra trick?
Status: UNCONFIRMED → NEW
QA Whiteboard: [bugday-20160829]
Component: Untriaged → DOM
Ever confirmed: true
Product: Firefox → Core
Does setting dom.webkitBlink.dirPicker.enabled to false in about:config fix this issue? Or setting dom.webkitBlink.filesystem.enabled to false? (I assume no, since the initial comment talks about FF48) Is this a regression?
The original report was for Firefox 48, I used the dev edition to create the bug while I tried things out in FF48. I just downloaded Nightly, 51.0a1 (2016-08-31) and tried the example page toggling the prefs above, and they did not seem to help the issue. More detail: * Set dom.webkitBlink.dirPicker.enabled to false, closed and restart the browser. Issue still there. * Reset dom.webkitBlink.dirPicker.enabled, then set dom.webkitBlink.filesystem.enabled to false, closed and restarted browser. Issue still there. * Set both prefs to false, closed and restarted browser. Issue still there.
Is this then a regression? Is FF48 the first release which had the issue or did also older releases have this?
This is the first time I tried this particular kind of file in Firefox, in FF48, so just know it is an issue there, and now on nightly. If there is a particular older version number or two that you want me to try, I could see about finding those to try them.
Any older build would be good to test. Say FF45esr and some esrs before that perhaps. esr38 and esr31.
I tried these ESR releases, did not set any special prefs, and they all behaved like 48/nightly -- showed the directory instead of treating it as a file: * 31.8.0 * 38.8.0 * 45.3.0
Thanks. Not a regression then. Since I'm not familiar with OSX conventions, I don't know what the right behavior here is, or how to fix this.
Michael, I feel like you know about this sort of thing. Can you take a quick look to confirm/deny my suspicion?
It sounds like there are two parts to this bug: (1) Tell the file open dialog that package directories should not be entered and should instead be treated as files, and (2) handle the uploading correctly. I don't know what (2) entails. We'd probably need to look at what Safari does. It looks like (1) can be done using [openDlg setTreatsFilePackagesAsDirectories:NO];.
I talked with Markus a bit. This isn't really the sort of thing I'm super familiar with. I understand why our code doesn't handle uploading these packages yet though, as Packages are not a single file. I imagine that we will have to upload them as directories using the webkit directory upload APIs, but we should check safari and do what they do.
About (2) part, here's some investigation results: steps: 1. prepare file upload form 2. run Chrome / Safari 3. click the file input 4. choose Grab.app package, that also can be chosen in file picker 5. submit what happens: * on Chrome, file input shows GUID like string (e.g. "C1CA7E13-6B0D-42AE-9560-C3203A9BADB1-48974-0005C478378BE970") * on Safari, file input shows "Grab.app" and on both: * input.value returns "C:\fakepath\Grab.app.zip" * when I upload, chrome uploads a zip file, with "Grab.app.zip" filename * the zip file contains Grab.app package so my assumption was wrong, sorry! they're not using directory feature, but just uploads single archive.
(In reply to Michael Layzell [:mystor] from comment #11) > I talked with Markus a bit. This isn't really the sort of thing I'm super > familiar with. I understand why our code doesn't handle uploading these > packages yet though, as Packages are not a single file. I imagine that we > will have to upload them as directories using the webkit directory upload > APIs, but we should check safari and do what they do. note, webkit doesn't support webkit directory upload API (webkitdirectory), so this isn't about that.
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-safari
You need to log in before you can comment on or make changes to this bug.