Bug 195366 - Make sure our .sb files are adjusted to look in /Library/Apple
Summary: Make sure our .sb files are adjusted to look in /Library/Apple
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: Safari 12
Hardware: Mac macOS 10.14
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-06 11:06 PST by Richard Houle
Modified: 2019-03-07 17:31 PST (History)
8 users (show)

See Also:


Attachments
Version 1 (987 bytes, patch)
2019-03-06 11:06 PST, Richard Houle
ews-watchlist: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews202 for win-future (12.95 MB, application/zip)
2019-03-06 13:13 PST, EWS Watchlist
no flags Details
Version 2 (2.85 KB, patch)
2019-03-07 16:38 PST, Richard Houle
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Houle 2019-03-06 11:06:12 PST
<rdar://problem/47749116> Make sure our .sb files are adjusted to look in /Library/Apple
Comment 1 Richard Houle 2019-03-06 11:06:47 PST
Created attachment 363761 [details]
Version 1
Comment 2 EWS Watchlist 2019-03-06 13:13:41 PST
Comment on attachment 363761 [details]
Version 1

Attachment 363761 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/11400538

New failing tests:
js/dom/custom-constructors.html
Comment 3 EWS Watchlist 2019-03-06 13:13:53 PST
Created attachment 363778 [details]
Archive of layout-test-results from ews202 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews202  Port: win-future  Platform: CYGWIN_NT-6.1-2.10.0-0.325-5-3-x86_64-64bit
Comment 4 Richard Houle 2019-03-06 13:19:32 PST
Windows build failure are unrelated.
Comment 5 Brent Fulgham 2019-03-06 13:22:31 PST
Comment on attachment 363761 [details]
Version 1

Isn't this change needed for the Network and Plugin Process, too?
Comment 6 Richard Houle 2019-03-06 13:24:37 PST
(In reply to Brent Fulgham from comment #5)
> Comment on attachment 363761 [details]
> Version 1
> 
> Isn't this change needed for the Network and Plugin Process, too?

It is only required because of the Injected Bundle.
Comment 7 mitz 2019-03-06 16:12:40 PST
(In reply to Richard Houle from comment #6)
> (In reply to Brent Fulgham from comment #5)
> > Comment on attachment 363761 [details]
> > Version 1
> > 
> > Isn't this change needed for the Network and Plugin Process, too?
> 
> It is only required because of the Injected Bundle.

Why can’t whoever specifies the injected bundle also use the _WKProcessPoolConfiguration property additionalReadAccessAllowedURLs instead of making this global change at the WebKit level?
Comment 8 Brent Fulgham 2019-03-06 17:07:12 PST
(In reply to mitz from comment #7)
> (In reply to Richard Houle from comment #6)
> > (In reply to Brent Fulgham from comment #5)
> > > Comment on attachment 363761 [details]
> > > Version 1
> > > 
> > > Isn't this change needed for the Network and Plugin Process, too?
> > 
> > It is only required because of the Injected Bundle.
> 
> Why can’t whoever specifies the injected bundle also use the
> _WKProcessPoolConfiguration property additionalReadAccessAllowedURLs instead
> of making this global change at the WebKit level?

Good point. That would be preferable to allowing any WebKit client to have access to this directory.

Richard: Can you try the approach where the UIProcess for this special case uses _WKProcessPoolConfiguration as mitz suggests?
Comment 9 Richard Houle 2019-03-07 16:37:36 PST
(In reply to mitz from comment #7)
> (In reply to Richard Houle from comment #6)
> > (In reply to Brent Fulgham from comment #5)
> > > Comment on attachment 363761 [details]
> > > Version 1
> > > 
> > > Isn't this change needed for the Network and Plugin Process, too?
> > 
> > It is only required because of the Injected Bundle.
> 
> Why can’t whoever specifies the injected bundle also use the
> _WKProcessPoolConfiguration property additionalReadAccessAllowedURLs instead
> of making this global change at the WebKit level?

Good suggestion.

I still need to submit a WebKit level change. Mac Safari still goes through the C-API (rather than _WKProcessPoolConfiguration.)
Comment 10 Richard Houle 2019-03-07 16:38:50 PST
Created attachment 363956 [details]
Version 2
Comment 11 mitz 2019-03-07 16:47:29 PST
(In reply to Richard Houle from comment #9)
> (In reply to mitz from comment #7)
> > (In reply to Richard Houle from comment #6)
> > > (In reply to Brent Fulgham from comment #5)
> > > > Comment on attachment 363761 [details]
> > > > Version 1
> > > > 
> > > > Isn't this change needed for the Network and Plugin Process, too?
> > > 
> > > It is only required because of the Injected Bundle.
> > 
> > Why can’t whoever specifies the injected bundle also use the
> > _WKProcessPoolConfiguration property additionalReadAccessAllowedURLs instead
> > of making this global change at the WebKit level?
> 
> Good suggestion.
> 
> I still need to submit a WebKit level change. Mac Safari still goes through
> the C-API (rather than _WKProcessPoolConfiguration.)

WKContextConfigurationRef is toll-free bridged to _WKProcessPoolConfiguration. There’s no need to add C API, because clients can cast and use the Objective-C API.
Comment 12 Richard Houle 2019-03-07 17:30:21 PST
(In reply to mitz from comment #11)
> (In reply to Richard Houle from comment #9)
> > (In reply to mitz from comment #7)
> > > (In reply to Richard Houle from comment #6)
> > > > (In reply to Brent Fulgham from comment #5)
> > > > > Comment on attachment 363761 [details]
> > > > > Version 1
> > > > > 
> > > > > Isn't this change needed for the Network and Plugin Process, too?
> > > > 
> > > > It is only required because of the Injected Bundle.
> > > 
> > > Why can’t whoever specifies the injected bundle also use the
> > > _WKProcessPoolConfiguration property additionalReadAccessAllowedURLs instead
> > > of making this global change at the WebKit level?
> > 
> > Good suggestion.
> > 
> > I still need to submit a WebKit level change. Mac Safari still goes through
> > the C-API (rather than _WKProcessPoolConfiguration.)
> 
> WKContextConfigurationRef is toll-free bridged to
> _WKProcessPoolConfiguration. There’s no need to add C API, because clients
> can cast and use the Objective-C API.

Thanks for pointing it out. It was not obvious my looking at the source code.