Bug 216909 – [Preferences] Start generating experimental feature preferences for legacy WebKit

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

[Sam Weinig]

[Preferences] Start generating experimental feature preferences for legacy WebKit

[Sam Weinig]

Created attachment 409519 [details]
Patch

[Sam Weinig]

Created attachment 409523 [details]
Patch

[Sam Weinig]

Created attachment 409525 [details]
Patch

[Alex Christensen]

Why do you think it's a good idea to do changes like this to WebKitLegacy, where we don't intend to do any big changes until we remove it?

[Sam Weinig]

Created attachment 409528 [details]
Patch

[Sam Weinig]

(In reply to Alex Christensen from comment #4)
> Why do you think it's a good idea to do changes like this to WebKitLegacy,
> where we don't intend to do any big changes until we remove it?

Because otherwise we will have to keep manually changing it in inconsistent and error prone ways every time features settings are added.

[Sam Weinig]

Created attachment 409570 [details]
Patch

[Sam Weinig]

Created attachment 409572 [details]
Patch

[Sam Weinig]

Created attachment 409578 [details]
Patch

[Sam Weinig]

Created attachment 409579 [details]
Patch

[Sam Weinig]

Created attachment 409590 [details]
Patch

[Sam Weinig]

I think this should be ready for review now.

[Sam Weinig]

(In reply to Sam Weinig from comment #12)
> I think this should be ready for review now.

Maybe not. iOS WebKitLegacy still has some issues.

[Sam Weinig]

Created attachment 409626 [details]
Patch

[Sam Weinig]

Now it is definitely ready for review.

[Sam Weinig]

Again, for reviewers, this is a stepping stone. Ultimate plan is to have these yaml files in WTF, and shared in someway between WebKitLegacy and WebKit2.

[Chris Dumez]

WebKitLegacy being deprecated and in maintenance mode, I am not convinced we want to expose experimental features there in general?

[Sam Weinig]

(In reply to Chris Dumez from comment #17)
> WebKitLegacy being deprecated and in maintenance mode, I am not convinced we
> want to expose experimental features there in general?

I am not sure what you are proposing here. Do you think it is better for everyone to just keep adding tons of additional WebPreferences code every time a new feature is added, because that is the status quo.

[Sam Weinig]

(In reply to Sam Weinig from comment #18)
> (In reply to Chris Dumez from comment #17)
> > WebKitLegacy being deprecated and in maintenance mode, I am not convinced we
> > want to expose experimental features there in general?
> 
> I am not sure what you are proposing here. Do you think it is better for
> everyone to just keep adding tons of additional WebPreferences code every
> time a new feature is added, because that is the status quo.

Chris has told me he is not opposed to landing this. So I am.

[EWS]

Committed r267575: <https://trac.webkit.org/changeset/267575>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 409626 [details].

[Radar WebKit Bug Importer]

<rdar://problem/69578216>

[Darin Adler]

I agree that we don’t need to add API for turning features on and off to Legacy WebKit. On the other hand, for testing purposes, if the feature is going to work in Legacy WebKit, then we want it to be testable in Legacy WebKit.

Ideally we can separate the API from how we enable disable things for testing and avoid adding and removing API or even SPI as we develop new web technology features.

Turning features still under development on and off in a Safari Technology Preview or a similar context is a sort of in-between case that is also important. Separate Objective-C methods or properties for each feature don’t necessarily need to exist just because we want that system.