Bug 216786
| Summary: | REGRESSION: Buttons on osm.org don't work | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | ManDay <manday> |
| Component: | UI Events | Assignee: | 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/ | ||
ManDay
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
Works fine in 3.38.0-16-gb0766c3a7+ (wkgtk 2.30). In which browser is this failing for you?
Philippe Normand
I take it back, clicking on "layers" indeed has no effect :)
Philippe Normand
If you *right* click though, stuff happens.
ManDay
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
<rdar://problem/73606232>
Sam Sneddon [:gsnedders]
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
(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]
(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]
See also: https://github.com/Leaflet/Leaflet/issues/7255
Sam Sneddon [:gsnedders]
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
(In reply to Sam Sneddon [:gsnedders] from comment #10)
> Propose we close this as wontfix, given OSM is now fixed?
Sounds good.