Bug 199917 – Add SPI _WKProcessPoolConfiguration.javaScriptConfigurationDirectory

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

[Alex Christensen]

Add SPI _WKWebsiteDataStoreConfiguration.javaScriptConfigurationDirectory

[Alex Christensen]

Created attachment 374419 [details]
Patch

[Alex Christensen]

Created attachment 374423 [details]
Patch

[Sam Weinig]

Is it currently possible to have two WKWebView's with different WKWebSiteDataStores using the same WebProcess? If so, does this work in that case?

[Alex Christensen]

I don't think it's possible any more, but even if it is, this is only used for some internal engineers so I don't think this SPI is a big deal.

[Alex Christensen]

(I'm trying to keep the status quo as much as possible while giving a client the ability to move away from WKContextCreateWithInjectedBundlePath)

[Sam Weinig]

(In reply to Alex Christensen from comment #4)
> I don't think it's possible any more, but even if it is, this is only used
> for some internal engineers so I don't think this SPI is a big deal.

Hm. Seems like it should be possible. What happens if you have a process pool created with _WKProcessPoolConfiguration.usesSingleWebProcess = YES, and then have two WKWebViews. 

Would it be acceptable to the client to have this be true for all processes in a process pool? If so, can it be moved to _WKProcessPoolConfiguration? Or would that break service workers?

Either way, seems worth testing what happens in the shared web process case.

[Alex Christensen]

Those are existing problems. I agree that this SPI isn't in the perfect place, but that's not the problem I'm trying to solve right now. Right now I'm trying to solve the problem that we can't migrate from WKContextCreateWithInjectedBundlePath. I'm trying to make that transition as close to no change as possible to minimize risk of regressions when making the switch. Once the switch has been made, we can move the location of this SPI in a smaller, easier-to-review patch. I will add a FIXME comment indicating my intent.

[Alex Christensen]

Created attachment 374470 [details]
Patch

[Sam Weinig]

(In reply to Alex Christensen from comment #7)
> Those are existing problems. I agree that this SPI isn't in the perfect
> place, but that's not the problem I'm trying to solve right now. Right now
> I'm trying to solve the problem that we can't migrate from
> WKContextCreateWithInjectedBundlePath. I'm trying to make that transition as
> close to no change as possible to minimize risk of regressions when making
> the switch. Once the switch has been made, we can move the location of this
> SPI in a smaller, easier-to-review patch. I will add a FIXME comment
> indicating my intent.

Given this is SPI you don't want anyone to use except the clients you are trying to move off the C SPI, I suggest giving it a name that explains that and putting the FIXME comment in the SPI header. That said, if you are going to ask the clients to move to another SPI in the future, it might make sense to make the change now, so they only have to make the change once.

That said, I still think you should be testing the shared web process case.

[Alex Christensen]

Created attachment 374526 [details]
Patch

[Alex Christensen]

I moved the SPI to _WKProcessPoolConfiguration. Now the shared web process case is not relevant.

[Alex Christensen]

http://trac.webkit.org/r247685

[Radar WebKit Bug Importer]

<rdar://problem/53403898>

[Alex Christensen]

All the tests were looking for (and not finding) the default JSC config file until http://trac.webkit.org/r247689