WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED MOVED
216786
REGRESSION: Buttons on osm.org don't work
https://bugs.webkit.org/show_bug.cgi?id=216786
Summary
REGRESSION: Buttons on osm.org don't work
ManDay
Reported
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).
Attachments
Add attachment
proposed patch, testcase, etc.
Philippe Normand
Comment 1
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?
Philippe Normand
Comment 2
2020-09-21 10:03:59 PDT
I take it back, clicking on "layers" indeed has no effect :)
Philippe Normand
Comment 3
2020-09-21 10:05:11 PDT
If you *right* click though, stuff happens.
ManDay
Comment 4
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).
Radar WebKit Bug Importer
Comment 5
2021-01-25 23:50:23 PST
<
rdar://problem/73606232
>
Sam Sneddon [:gsnedders]
Comment 6
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?
Carlos Garcia Campos
Comment 7
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.
Sam Sneddon [:gsnedders]
Comment 8
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].
Sam Sneddon [:gsnedders]
Comment 9
2022-05-10 07:25:46 PDT
See also:
https://github.com/Leaflet/Leaflet/issues/7255
Sam Sneddon [:gsnedders]
Comment 10
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?
Michael Catanzaro
Comment 11
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug