1298474 - Mac package format for Pages cannot be uploaded

Status: NEW

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

Description

[James Burke [:jrburke]]

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

Comment 1

[Tooru Fujisawa [:arai]]

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?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

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?

Comment 3

[James Burke [: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.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Is this then a regression? Is FF48 the first release which had the issue or did also older releases have this?

Comment 5

[James Burke [: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.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Any older build would be good to test. Say FF45esr and some esrs before that perhaps.
esr38 and esr31.

Comment 7

[James Burke [:jrburke]]

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

[Olli Pettay [:smaug][[e-mail]]]

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

[Andrew Overholt [:overholt]]

Michael, I feel like you know about this sort of thing. Can you take a quick look to confirm/deny my suspicion?

Comment 10

[Markus Stange [:mstange]]

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

[Nika Layzell [:nika] (ni? for response)]

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.

Comment 12

[Tooru Fujisawa [:arai]]

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

[Olli Pettay [:smaug][[e-mail]]]

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

Comment 14

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)