[Webkit-unassigned] [Bug 216586] New: Make Settings generated from Settings.yaml work with Workers

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=216586

            Bug ID: 216586
           Summary: Make Settings generated from Settings.yaml work with
                    Workers
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sam at webkit.org

The biggest hurdle to deal with for moving off of RuntimeEnabledFeatures is making the settings generated from Settings.yaml work with Workers. Specifically, making it so that IDL interfaces exposed to workers can use the EnabledBySetting=Foo syntax to indicate that an interface/operation/attribute is conditionally available based on Settings. (Currently, interfaces/operations/attribute that need this use EnabledAtRuntime, which uses RuntimeEnabledFeatures in a thread unsafe way).

I am not sure what the best way to go about this would be. 


Regardless of the technique we end up going, the end goal for the bindings will probably look pretty much the same. We will go from checks that look like:

downcast<Document>(jsCast<JSDOMGlobalObject*>(globalObject)->scriptExecutionContext())->settings()->isFooEnabled()

to:

jsCast<JSDOMGlobalObject*>(globalObject)->scriptExecutionContext()->settings()->isFooEnabled();


What exactly ScriptExecutionContext::settings() returns, and how it is populated is what we need to figure out.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200915/a73bb9c0/attachment-0001.htm>