Bug 216786

Summary: REGRESSION: Buttons on osm.org don't work
Product: WebKit Reporter: ManDay <manday>
Component: UI EventsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED MOVED    
Severity: Normal CC: bugs-noreply, cgarcia, gsnedders, mcatanzaro, pnormand, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 14   
Hardware: Unspecified   
OS: Unspecified   
URL: https://www.openstreetmap.org/

Description ManDay 2020-09-21 09:53:36 PDT
The buttons on the right hand side of openstreetmap.org stopped working from the 30.0 release on (e.g. "Layers" or "Query", only the "+" "-" buttons seem to be working).
Comment 1 Philippe Normand 2020-09-21 10:03:01 PDT
Works fine in 3.38.0-16-gb0766c3a7+ (wkgtk 2.30). In which browser is this failing for you?
Comment 2 Philippe Normand 2020-09-21 10:03:59 PDT
I take it back, clicking on "layers" indeed has no effect :)
Comment 3 Philippe Normand 2020-09-21 10:05:11 PDT
If you *right* click though, stuff happens.
Comment 4 ManDay 2020-09-21 12:28:20 PDT
Ah, interesting. Yes, can confirm, right click has the effect that left click should have plus the effect that right click has (NB: as opposed to, say, firefox 80, where right click does not have a simultaneous left click effect).
Comment 5 Radar WebKit Bug Importer 2021-01-25 23:50:23 PST
<rdar://problem/73606232>
Comment 6 Sam Sneddon [:gsnedders] 2021-01-26 04:37:38 PST
A quick look appears to show that we do actually show (from the pointerup event) then hide (from the click event) the panel. Firefox seems to end up with a completely different pointerup event handler being run, so things seemingly have already gone wrong by that point.

Am curious as to whether this is regressed in Saf13 or Saf14, as Saf13 was when pointer events shipped, but the regression window at first glance is gonna be pretty massive.

Did WebKitGTK not enable pointer events till 2.30, or what else could've caused the regression to happen so much later there?
Comment 7 Carlos Garcia Campos 2021-01-26 04:59:12 PST
(In reply to Sam Sneddon [:gsnedders] from comment #6)
> A quick look appears to show that we do actually show (from the pointerup
> event) then hide (from the click event) the panel. Firefox seems to end up
> with a completely different pointerup event handler being run, so things
> seemingly have already gone wrong by that point.
> 
> Am curious as to whether this is regressed in Saf13 or Saf14, as Saf13 was
> when pointer events shipped, but the regression window at first glance is
> gonna be pretty massive.
> 
> Did WebKitGTK not enable pointer events till 2.30, or what else could've
> caused the regression to happen so much later there?

They were enabled in 2.28, I think, see bug #202789, it landed in Nov 2019.
Comment 8 Sam Sneddon [:gsnedders] 2022-05-10 06:07:15 PDT
(In reply to Sam Sneddon [:gsnedders] from comment #6)
> Am curious as to whether this is regressed in Saf13 or Saf14, as Saf13 was
> when pointer events shipped, but the regression window at first glance is
> gonna be pretty massive.


From Radar:

> This behavior reproduces on Safari 13.1.3 [on Catalina].
> Works on Safari 12.1.2 [on Mojave].
Comment 9 Sam Sneddon [:gsnedders] 2022-05-10 07:25:46 PDT
See also: https://github.com/Leaflet/Leaflet/issues/7255
Comment 10 Sam Sneddon [:gsnedders] 2022-05-10 08:30:48 PDT
Ah, the underlying thing here is we support both touch events and pointer events.

So it's unclear that there would be any possible fix here aside from disabling pointer events conditionally… and this has been fixed osm.org by updating Leaflet to a newer version.

Propose we close this as wontfix, given OSM is now fixed?
Comment 11 Michael Catanzaro 2022-05-10 09:45:42 PDT
(In reply to Sam Sneddon [:gsnedders] from comment #10)
> Propose we close this as wontfix, given OSM is now fixed?

Sounds good.