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)
Tracking
()
NEW
People
(Reporter: jrburke, Unassigned)
Details
(Keywords: parity-chrome, parity-safari)
Attachments
(1 file)
182 bytes,
text/html
|
Details |
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.
Comment 1•9 years ago
|
||
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]
Comment 2•9 years ago
|
||
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)
Reporter | ||
Comment 3•9 years ago
|
||
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.
Reporter | ||
Updated•9 years ago
|
Flags: needinfo?(jrburke)
Comment 4•9 years ago
|
||
Is this then a regression? Is FF48 the first release which had the issue or did also older releases have this?
Flags: needinfo?(jrburke)
Reporter | ||
Comment 5•9 years ago
|
||
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)
Comment 6•9 years ago
|
||
Any older build would be good to test. Say FF45esr and some esrs before that perhaps.
esr38 and esr31.
Reporter | ||
Comment 7•9 years ago
|
||
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
Comment 8•9 years ago
|
||
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.
Comment 9•9 years ago
|
||
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)
Comment 10•9 years ago
|
||
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];.
Comment 11•9 years ago
|
||
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)
Comment 12•9 years ago
|
||
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.
Comment 13•9 years ago
|
||
(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.
Updated•9 years ago
|
Priority: -- → P3
![]() |
||
Comment 14•7 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome,
parity-safari
Whiteboard: [parity-chrome][parity-safari]
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•