Open Bug 1298474 Opened 9 years ago Updated 3 years ago

Mac package format for Pages cannot be uploaded

Categories

(Core :: DOM: Core & HTML, defect, P3)

48 Branch
defect

Tracking

()

People

(Reporter: jrburke, Unassigned)

Details

(Keywords: parity-chrome, parity-safari)

Attachments

(1 file)

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
Whiteboard: [parity-chrome][parity-safari]
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?
Flags: needinfo?(jrburke)
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.
Flags: needinfo?(jrburke)
Is this then a regression? Is FF48 the first release which had the issue or did also older releases have this?
Flags: needinfo?(jrburke)
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.
Flags: needinfo?(jrburke)
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?
Flags: needinfo?(michael)
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.
Flags: needinfo?(michael)
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.
Priority: -- → P3
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-chrome][parity-safari]
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: