Mac package format for Pages cannot be uploaded

NEW
Unassigned

Status

()

P3
normal
2 years ago
6 months ago

People

(Reporter: jrburke, Unassigned)

Tracking

({parity-chrome, parity-safari})

48 Branch
parity-chrome, parity-safari
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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
Whiteboard: [parity-chrome][parity-safari]

Comment 2

2 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

2 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

2 years ago
Flags: needinfo?(jrburke)

Comment 4

2 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

2 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

2 years ago
Any older build would be good to test. Say FF45esr and some esrs before that perhaps.
esr38 and esr31.
(Reporter)

Comment 7

2 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

2 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.
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];.

Comment 11

2 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)
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.

Updated

2 years ago
Priority: -- → P3
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]
You need to log in before you can comment on or make changes to this bug.