Bug 183489 – [Mac] WebKit fails to receive file promises when the embedding app is sandboxed

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Andy Estes]

[Mac] WebKit fails to receive file promises when the embedding app is sandboxed

[Andy Estes]

rdar://problem/38267517

[Andy Estes]

Created attachment 335372 [details]
Patch

[EWS Watchlist]

Comment on attachment 335372 [details]
Patch

Attachment 335372 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/6867732

New failing tests:
editing/pasteboard/file-input-files-access-promise.html

[EWS Watchlist]

Created attachment 335380 [details]
Archive of layout-test-results from ews100 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-sierra  Platform: Mac OS X 10.12.6

[EWS Watchlist]

Comment on attachment 335372 [details]
Patch

Attachment 335372 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/6868012

New failing tests:
editing/pasteboard/file-input-files-access-promise.html

[EWS Watchlist]

Created attachment 335383 [details]
Archive of layout-test-results from ews114 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114  Port: mac-sierra  Platform: Mac OS X 10.12.6

[Andy Estes]

Created attachment 335391 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 335391 [details]
Patch

Clearing flags on attachment: 335391

Committed r229462: <https://trac.webkit.org/changeset/229462>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Darin Adler]

Comment on attachment 335391 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=335391&action=review

> Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:3742
>                  if (errorOrNil)
>                      return;

Seems that both dragData and fileNames might leak if we don’t eventually get all the files we expect; I don’t understand how the error handling works here. Also seems we have two identical copies of this code, here and in legacy WebKit, so I guess the code is pretty old. I think it could be factored more cleanly so the call to performDragOperation isn’t nested so deep inside both blocks and loops.

[Andy Estes]

(In reply to Darin Adler from comment #10)
> Comment on attachment 335391 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=335391&action=review
> 
> > Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:3742
> >                  if (errorOrNil)
> >                      return;
> 
> Seems that both dragData and fileNames might leak if we don’t eventually get
> all the files we expect; I don’t understand how the error handling works
> here. Also seems we have two identical copies of this code, here and in
> legacy WebKit, so I guess the code is pretty old. I think it could be
> factored more cleanly so the call to performDragOperation isn’t nested so
> deep inside both blocks and loops.

I agree. I have an idea for how to clean this up and get rid of the manual memory management.