Bug 216786 - REGRESSION: Buttons on osm.org don't work
Summary: REGRESSION: Buttons on osm.org don't work
Status: RESOLVED MOVED
Alias: None
Product: WebKit
Classification: Unclassified
Component: UI Events (show other bugs)
Version: Safari 14
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: https://www.openstreetmap.org/
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-09-21 09:53 PDT by ManDay
Modified: 2022-05-10 09:45 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.