Bug 208655 – Remove the experimental flag for Pointer Events

• Component: UI Events
• Status: RESOLVED FIXED

[Antoine Quint]

Pointer Events have been on by default for long enough, we should remove it as an experimental feature now.

[Radar WebKit Bug Importer]

<rdar://problem/60090545>

[Antoine Quint]

Created attachment 392688 [details]
Patch

[Antoine Quint]

Created attachment 392689 [details]
Patch

[Dean Jackson]

Comment on attachment 392689 [details]
Patch

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

Wouldn't you also have to edit every test that has experimental:PointerEventsEnabled flags?

I think you should remove the compile guard at the same time.

And obviously the bots are not happy :)

> Source/WebCore/dom/Element.idl:105
> +    [Conditional=POINTER_EVENTS, MayThrowException] void setPointerCapture(long pointerId);
> +    [Conditional=POINTER_EVENTS, MayThrowException] void releasePointerCapture(long pointerId);
> +    [Conditional=POINTER_EVENTS] boolean hasPointerCapture(long pointerId);

Why wouldn't you remove the compile time flag at the same time?

> Source/WebKitLegacy/mac/WebView/WebPreferences.mm:3248
>  - (void)setSyntheticEditingCommandsEnabled:(BOOL)flag
>  {
> -    [self _setBoolValue:flag forKey:WebKitPointerEventsEnabledPreferenceKey];
> +    [self _setBoolValue:flag forKey:WebKitSyntheticEditingCommandsEnabledPreferenceKey];
>  }

Whhhhaaaat?

[Dean Jackson]

(In reply to Dean Jackson from comment #4)
> Comment on attachment 392689 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=392689&action=review
> 
> Wouldn't you also have to edit every test that has
> experimental:PointerEventsEnabled flags?

Oh. I see they were the only two.

[Antoine Quint]

(In reply to Dean Jackson from comment #4)
> I think you should remove the compile guard at the same time.

Some platforms disable Pointer Events at compile-time, we should honor that still.

> And obviously the bots are not happy :)

Looking into that.

> > Source/WebKitLegacy/mac/WebView/WebPreferences.mm:3248
> >  - (void)setSyntheticEditingCommandsEnabled:(BOOL)flag
> >  {
> > -    [self _setBoolValue:flag forKey:WebKitPointerEventsEnabledPreferenceKey];
> > +    [self _setBoolValue:flag forKey:WebKitSyntheticEditingCommandsEnabledPreferenceKey];
> >  }
> 
> Whhhhaaaat?

Yeah! I expect this was a cut-and-paste issue when the SyntheticEditingCommandsEnabled flag was added.

[Antoine Quint]

Created attachment 392706 [details]
Patch

[Antoine Quint]

Committed r257978: <https://trac.webkit.org/changeset/257978>

[Darin Adler]

Comment on attachment 392706 [details]
Patch

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

I guess this is OK. If not all platforms have this feature enabled, I could imagine some might still want an experimental runtime flag for it. Typically I’d expect us to remove the runtime flag at the same time as we remove the compile-time flag.

What platforms have POINTER_EVENTS off?

> Source/WebCore/dom/NavigatorMaxTouchPoints.idl:31
> +    Conditional=POINTER_EVENTS

I think our tradition is to sort these alphabetically instead of having them in an arbitrary order and put commas on every line so it’s easy to add and remove lines without a special case for the last line.

> Source/WebKitLegacy/mac/WebView/WebPreferences.mm:3243
>  - (BOOL)syntheticEditingCommandsEnabled
>  {
> -    return [self _boolValueForKey:WebKitPointerEventsEnabledPreferenceKey];
> +    return [self _boolValueForKey:WebKitSyntheticEditingCommandsEnabledPreferenceKey];
>  }

Oops!

I guess no one was using this?

> Source/WebKitLegacy/mac/WebView/WebPreferences.mm:3248
>  - (void)setSyntheticEditingCommandsEnabled:(BOOL)flag
>  {
> -    [self _setBoolValue:flag forKey:WebKitPointerEventsEnabledPreferenceKey];
> +    [self _setBoolValue:flag forKey:WebKitSyntheticEditingCommandsEnabledPreferenceKey];
>  }

Oops!

> Source/WebKitLegacy/mac/WebView/WebPreferencesPrivate.h:-590
> -- (void)setPointerEventsEnabled:(BOOL)flag;
> -- (BOOL)pointerEventsEnabled;

This is a Private.h header, so SPI. How do we know no one is calling it? In the past we sometimes leave these methods around and just empty their bodies out.

[Antoine Quint]

(In reply to Darin Adler from comment #9)
> Comment on attachment 392706 [details]
> Patch

This didn't actually need to be reviewed, dino had reviewed an earlier patch and the r+ got lost on the way. Sorry I hadn't reset the r? flag.

> View in context:
> https://bugs.webkit.org/attachment.cgi?id=392706&action=review
> 
> I guess this is OK. If not all platforms have this feature enabled, I could
> imagine some might still want an experimental runtime flag for it. Typically
> I’d expect us to remove the runtime flag at the same time as we remove the
> compile-time flag.
> 
> What platforms have POINTER_EVENTS off?

All versions of tvOS and watchOS < 6.0. I'm looking into the possibility of removing the compile-time flag as well.

> > Source/WebCore/dom/NavigatorMaxTouchPoints.idl:31
> > +    Conditional=POINTER_EVENTS
> 
> I think our tradition is to sort these alphabetically instead of having them
> in an arbitrary order and put commas on every line so it’s easy to add and
> remove lines without a special case for the last line.
> 
> > Source/WebKitLegacy/mac/WebView/WebPreferences.mm:3243
> >  - (BOOL)syntheticEditingCommandsEnabled
> >  {
> > -    return [self _boolValueForKey:WebKitPointerEventsEnabledPreferenceKey];
> > +    return [self _boolValueForKey:WebKitSyntheticEditingCommandsEnabledPreferenceKey];
> >  }
> 
> Oops!
> 
> I guess no one was using this?
> 
> > Source/WebKitLegacy/mac/WebView/WebPreferences.mm:3248
> >  - (void)setSyntheticEditingCommandsEnabled:(BOOL)flag
> >  {
> > -    [self _setBoolValue:flag forKey:WebKitPointerEventsEnabledPreferenceKey];
> > +    [self _setBoolValue:flag forKey:WebKitSyntheticEditingCommandsEnabledPreferenceKey];
> >  }
> 
> Oops!

Yes, this was an oversight introduced in r246444.

> > Source/WebKitLegacy/mac/WebView/WebPreferencesPrivate.h:-590
> > -- (void)setPointerEventsEnabled:(BOOL)flag;
> > -- (BOOL)pointerEventsEnabled;
> 
> This is a Private.h header, so SPI. How do we know no one is calling it? In
> the past we sometimes leave these methods around and just empty their bodies
> out.

My expectation was that no one was using this SPI and that it was merely introduced to mimic a prior run-time flag that added one.

[Darin Adler]

Comment on attachment 392706 [details]
Patch

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

>>> Source/WebKitLegacy/mac/WebView/WebPreferencesPrivate.h:-590
>>> -- (BOOL)pointerEventsEnabled;
>> 
>> This is a Private.h header, so SPI. How do we know no one is calling it? In the past we sometimes leave these methods around and just empty their bodies out.
> 
> My expectation was that no one was using this SPI and that it was merely introduced to mimic a prior run-time flag that added one.

I think the guess makes sense. But we’d typically want to confirm that somehow.

[Antoine Quint]

The compile-time flag was removed in r258148, see bug 208821.