Bug 208655 - Remove the experimental flag for Pointer Events
Summary: Remove the experimental flag for Pointer Events
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: UI Events (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Antoine Quint
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-03-05 10:47 PST by Antoine Quint
Modified: 2020-03-09 14:02 PDT (History)
10 users (show)

See Also:


Attachments
Patch (15.74 KB, patch)
2020-03-06 00:56 PST, Antoine Quint
no flags Details | Formatted Diff | Diff
Patch (18.19 KB, patch)
2020-03-06 01:09 PST, Antoine Quint
no flags Details | Formatted Diff | Diff
Patch (18.09 KB, patch)
2020-03-06 05:00 PST, Antoine Quint
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Quint 2020-03-05 10:47:50 PST
Pointer Events have been on by default for long enough, we should remove it as an experimental feature now.
Comment 1 Radar WebKit Bug Importer 2020-03-05 10:48:07 PST
<rdar://problem/60090545>
Comment 2 Antoine Quint 2020-03-06 00:56:49 PST
Created attachment 392688 [details]
Patch
Comment 3 Antoine Quint 2020-03-06 01:09:10 PST
Created attachment 392689 [details]
Patch
Comment 4 Dean Jackson 2020-03-06 01:47:13 PST
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?
Comment 5 Dean Jackson 2020-03-06 01:52:16 PST
(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.
Comment 6 Antoine Quint 2020-03-06 04:55:03 PST
(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.
Comment 7 Antoine Quint 2020-03-06 05:00:44 PST
Created attachment 392706 [details]
Patch
Comment 8 Antoine Quint 2020-03-06 06:22:18 PST
Committed r257978: <https://trac.webkit.org/changeset/257978>
Comment 9 Darin Adler 2020-03-08 23:23:03 PDT
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.
Comment 10 Antoine Quint 2020-03-09 06:29:54 PDT
(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.
Comment 11 Darin Adler 2020-03-09 10:01:30 PDT
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.
Comment 12 Antoine Quint 2020-03-09 14:02:52 PDT
The compile-time flag was removed in r258148, see bug 208821.