Closed Bug 1746304 Opened 3 years ago Closed 2 years ago

Fling scrolls unintuitively gets captured by elements on page

Categories

(Core :: Panning and Zooming, defect, P3)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1168182

People

(Reporter: mcomella, Unassigned)

References

Details

Attachments

(2 files)

Attached video Video of the issue (deleted) —

Steps to reproduce

Expected behavior

Page continues to scroll as cursor goes over map element

Actual behavior

Page scrolling stops when cursor hits map element and map element starts to zoom out. Chrome has the expected behavior.

Nightly 97.0a1 12/14 on macOS 11.6.1.

I suspect the underlying cause here may be the same as bug 1199737, though the symptoms are a bit different.

Severity: -- → S3
Priority: -- → P3

Bug 1199737 is about zooming the webpage it seems? This is about the webpage handling scroll events and using them to perform some action (in this case zooming a map).

I observe a difference in handling non-flings: if you start scrolling (two finger pan on touchpad) and then you cursor is moved over the map in Firefox we immediately start zooming, whereas Safari and Chrome will keep scrolling. Safari and Chrome will only start zooming the map under the cursor if you lift you fingers and start another pan. You can pause, change direction, etc. This behaviour seems more desirable, I've run into it in other places (but I wasn't aware it was a difference in browsers), for example this page https://weather.gc.ca/map_e.html?layers=radar&zoom=7&center=49.22362589%2C-90.26372876

(In reply to Timothy Nikkel (:tnikkel) from comment #2)

Bug 1199737 is about zooming the webpage it seems? This is about the webpage handling scroll events and using them to perform some action (in this case zooming a map).

Sorry, I should have been more specific about the connection I had in mind: it seems that both bug 1199737 and this bug are artifacts of the operating system continuing to send events that cause scrolling (wheel or pan gesture) during the momentum phase, and us treating the momentum-phase events the same as regular non-momentum events in relevant places.

The difference that I observed here does not come during momentum events.

(In reply to Timothy Nikkel (:tnikkel) from comment #4)

The difference that I observed here does not come during momentum events.

What you described in comment 2 seems like an additional issue.

Let's suppose the issue is related to APZ hit testing. (That's an educated guess, maybe it's something slightly different like an interaction between APZ hit testing and preventDefault() handling.) The issue as reported might then be fixed by not doing hit testing for events in the momentum phase, but rather reusing the hit target from the input block for previous events.

To fix the issue you described, we'd need to apply that fix not only to events in the momentum phase, but to any event in the input block other than the first. That seems like a broader and potentially riskier change, so I think it makes sense to treat it separately.

Okay, I filed bug 1746967 for that issue.

I think Timothy meant Bug 1746967 in the previous comment.

For this https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-122.4196

  • scroll { target: HTMLDocument https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-122.4196#.YdY7Nt-xjRl, isTrusted: true, view: Window, detail: 0, layerX: 0, layerY: 0, which: 0, rangeOffset: 0, SCROLL_PAGE_UP: -32768, SCROLL_PAGE_DOWN: 32768, … } addthis_widget.js:70:317355
  • scroll { target: HTMLDocument https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-122.4196#.YdY7Nt-xjRl, isTrusted: true, view: Window, detail: 0, layerX: 0, layerY: 0, which: 0, rangeOffset: 0, SCROLL_PAGE_UP: -32768, SCROLL_PAGE_DOWN: 32768, … } addthis_widget.js:70:317355
  • scroll { target: HTMLDocument https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-122.4196#.YdY7Nt-xjRl, isTrusted: true, view: Window, detail: 0, layerX: 0, layerY: 0, which: 0, rangeOffset: 0, SCROLL_PAGE_UP: -32768, SCROLL_PAGE_DOWN: 32768, … } addthis_widget.js:70:317355

As soon as it crossed the canvas area it activated wheel.

  • wheel { target: canvas.ol-unselectable, buttons: 0, clientX: 1210, clientY: 409, layerX: 336, layerY: 1 } ol-4.6.4.js:formatted:1048
  • undefined ol-4.6.4.js:formatted:4151
  • scroll { target: HTMLDocument https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-122.4196#.YdY7Nt-xjRl, isTrusted: true, view: Window, detail: 0, layerX: 0, layerY: 0, which: 0, rangeOffset: 0, SCROLL_PAGE_UP: -32768, SCROLL_PAGE_DOWN: 32768, … } addthis_widget.js:70:317355
  • 23153.32 ol-4.6.4.js:formatted:3876
  • wheel { target: canvas.ol-unselectable, buttons: 0, clientX: 1210, clientY: 409, layerX: 336, layerY: 2 } ol-4.6.4.js:formatted:1048
  • undefined ol-4.6.4.js:formatted:4151
  • 23207.34 ol-4.6.4.js:formatted:3876
  • wheel { target: canvas.ol-unselectable, buttons: 0, clientX: 1210, clientY: 409, layerX: 336, layerY: 2 } ol-4.6.4.js:formatted:1048
  • undefined ol-4.6.4.js:formatted:4151
  • 23221.88 ol-4.6.4.js:formatted:3876

BUT there are moments I didn't get exactly the same behavior. I had only scroll events and sometimes a delayed zoomed by steps.

Also not the first time, there are issues with addthis_widget.js

I think bug 1614358 is another example of the same issue.

Attached file prevent-default.html (deleted) —

Simplified test page for reproducing the issue.

Status: NEW → RESOLVED
Closed: 2 years ago
Duplicate of bug: 1168182
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: