<rdar://problem/32224510>
Created attachment 313192 [details] Patch
Actually, this is <rdar://problem/32521025>
Created attachment 313193 [details] Patch
Created attachment 313194 [details] Fix Mac build
Comment on attachment 313194 [details] Fix Mac build Attachment 313194 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3947006 New failing tests: webrtc/video-replace-muted-track.html
Created attachment 313196 [details] Archive of layout-test-results from ews126 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews126 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.5
Comment on attachment 313194 [details] Fix Mac build View in context: https://bugs.webkit.org/attachment.cgi?id=313194&action=review > Source/WebCore/platform/ios/PasteboardIOS.mm:309 > +NSArray *Pasteboard::supportedFileUploadPasteboardTypes() > +{ > + return @[ (NSString *)kUTTypeContent, (NSString *)kUTTypeZipArchive ]; > +} Is this really iOS specific, or are these also the types we would want to allow for uploading on macOS as well? Or are things so different that it can't be shared?
Comment on attachment 313194 [details] Fix Mac build View in context: https://bugs.webkit.org/attachment.cgi?id=313194&action=review >> Source/WebCore/platform/ios/PasteboardIOS.mm:309 >> +} > > Is this really iOS specific, or are these also the types we would want to allow for uploading on macOS as well? Or are things so different that it can't be shared? The way file uploads work w.r.t. the pasteboard is much different on iOS. On Mac, there's no notion of "supported types" for file uploads, since the source will vend either NSFilesPromisePboardType or NSFilenamesPboardType in the pasteboard, explicitly indicating that the pasteboard contains a file. On iOS, these types don't exist (while kUTTypeFileURL exists, its use is strongly discouraged, and not supported by any system apps). Therefore, on iOS, we need to infer whether certain item providers can be files or not based on their registered UTIs. For this reason, we already support uploading .zip files on Mac because the file will contain either NSFilesPromisePboardType or NSFilenamesPboardType, but unfortunately, the model for providing files on iOS is completely different, so we need this iOS-specific handling here :/
(In reply to Wenson Hsieh from comment #8) > Comment on attachment 313194 [details] > Fix Mac build > > View in context: > https://bugs.webkit.org/attachment.cgi?id=313194&action=review > > >> Source/WebCore/platform/ios/PasteboardIOS.mm:309 > >> +} > > > > Is this really iOS specific, or are these also the types we would want to allow for uploading on macOS as well? Or are things so different that it can't be shared? > > The way file uploads work w.r.t. the pasteboard is much different on iOS. On > Mac, there's no notion of "supported types" for file uploads, since the > source will vend either NSFilesPromisePboardType or NSFilenamesPboardType in > the pasteboard, explicitly indicating that the pasteboard contains a file. > On iOS, these types don't exist (while kUTTypeFileURL exists, its use is > strongly discouraged, and not supported by any system apps). Therefore, on > iOS, we need to infer whether certain item providers can be files or not > based on their registered UTIs. > > For this reason, we already support uploading .zip files on Mac because the > file will contain either NSFilesPromisePboardType or NSFilenamesPboardType, > but unfortunately, the model for providing files on iOS is completely > different, so we need this iOS-specific handling here :/ Then again, we could just implement supportedFileUploadPasteboardTypes on Mac to return NSFilesPromisePboardType and NSFilenamesPboardType. It's a *little bit* weird, since supportedFileUploadPasteboardTypes on iOS describes "what types of content we are allowed to consider as files via type conformance", whereas on Mac, this would mean something more like "what pasteboard identifiers indicate that the source added a file". But even in the Mac case, we should be able to just use UTTypeConformsTo anyways since NSFilenamesPboardType and NSFilesPromisePboardType are effectively private UTIs, so the UTTypeConformsTo check would reduce to checking string equality, which is what we do now. I actually like this approach, since it would allow us to remove the platform-specific guards in DragData::containsFiles.
Created attachment 313215 [details] Unify DragData::containsFiles on Mac/iOS
Comment on attachment 313215 [details] Unify DragData::containsFiles on Mac/iOS Clearing flags on attachment: 313215 Committed r218508: <http://trac.webkit.org/changeset/218508>
All reviewed patches have been landed. Closing bug.