Closed Bug 1591250 Opened 6 years ago Closed 4 years ago

Can't pan on google maps

Categories

(Core :: DOM: Events, defect, P2)

Product:
Core
Component:
DOM: Events
Version:
70 Branch
Platform:
Unspecified
Android
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1669729
Project Flags:
Webcompat Priority P1

People

(Reporter: ksenia, Assigned: edgar)

References

(Regression,
URL
)

Details

(Keywords: regression)

Attachments

(2 files)

Directions panel not completely hidden ==> bug occurs
657.09 KB, image/png
Details
Directions panel completely hidden ==> bug does not occur
656.58 KB, image/png
Details

As reported here https://github.com/webcompat/web-bugs/issues/42680

Steps to reproduce:

  1. On Firefox Preview/ Preview Nightly visit https://www.google.com/maps/@43.6454689,-79.4104931,14z
  2. Swipe down "Directions" panel
  3. Try to navigate to the left of the map by panning

Expected:
Can navigate to the left

Actual:
Map doesn't move

Note that navigating to the right works in this scenario. Also it works if I don't swipe down "Directions" panel.

Disabling dom.w3c_pointer_events fixes the issue

from mozregression:

 8:26.06 INFO: Last good revision: f905e06aac2b9fdcade9afcd4ae59a9a66443dcc
 8:26.06 INFO: First bad revision: 1e64b8a0c546a49459d404aaf930d5b1f621246a
 8:26.06 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f905e06aac2b9fdcade9afcd4ae59a9a66443dcc&tochange=1e64b8a0c546a49459d404aaf930d5b1f621246a

 8:26.63 INFO: ************* Switching to mozilla-central
 8:26.99 ERROR: Unable to exploit the merge commit. Origin branch is mozilla-inbound, and the commit message for 1e64b8a0 was:
Merge inbound to mozilla-central. a=merge
Webcompat Priority: --- → ?
Priority: -- → P2

WFM, though perhaps I get different version of google maps, since it is localized to Finnish.

WFM too. Mine is localized to Traditional Chinese.

Working here for me in Firefox Preview Nightly and non-Nightly. It did reproduce for Adam (in Canada) in non-Nightly, but not Nightly. Ksenia, could you please re-test?

Flags: needinfo?(kberezina)

Yeah, still reproducible in both Firefox Preview Nightly and non-Nightly, also can reproduce with non English locale

Flags: needinfo?(kberezina)

We should probably try to figure this out before Fenix goes to production - not being able to pan Google Maps, DDG maps, and others seems bad.

Webcompat Priority: ? → P1

FWIW I just tried this on David Bolter's phone running the 2019-12-0 Fenix nightly (GV 2019-12-02-09:12:09) -- with a presumably Canadian-localized Google Maps -- and I was able to pan left and right. I did notice some pan actions were "lost" (I had to swipe more than once to make them take effect).

Ksenia, can we look at your device in person some day?

Flags: needinfo?(kberezina)

Sure, I'm planning to be in the office this week on Wed and Friday (11th & 13th), or next week works too.

Flags: needinfo?(kberezina)

FYI, the device I'm able to reproduce this is Samsung Galaxy S5 (SM-G900M), Android 6.0.1

Edgar, what sort of logs can Ksenia collect that will help diagnose the problem?

Flags: needinfo?(echen)

I don't think we have any logging for this kind of case.

(In reply to Andrew Overholt [:overholt] from comment #10)

Edgar, what sort of logs can Ksenia collect that will help diagnose the problem?

No, we don't have any logging, AFAIK.

I could not reproduce with my android device (which is HTC U11+, Android 9). Maybe this is a phone-related or Android-version-related issue? I could try to provide a debug version of apk which print some log to see if we could get some clue. (keep the ni? to me)

FWIW, I haven't managed to reproduced this with Android 6. (Comment 9 was about an Android 6 device)

Can anyone reproduce the issue on duckduckgo maps? It seems more severe. For example, https://duckduckgo.com/?q=Moissy-Cramayel%2C+France&iaxm=maps&ia=weather&strict_bbox=1&bbox=48.644085389625474%2C2.5339095042968722%2C48.601761012474356%2C2.6575056957031222&iai=13660372457170534124

Also, from the webcompat issue looks like Sergiu is able to reproduce it on Samsung Galaxy S8 (Android 9).

(In reply to Ksenia Berezina [:ksenia] from comment #14)

Can anyone reproduce the issue on duckduckgo maps?

Also, from the webcompat issue looks like Sergiu is able to reproduce it on Samsung Galaxy S8 (Android 9).

I could reproduce on duckduckgo maps with the steps from https://github.com/webcompat/web-bugs/issues/42962#issuecomment-547346640 (panning doesn't work after zoom-in/out).

(In reply to Edgar Chen [:edgar] from comment #15)

I could reproduce on duckduckgo maps with the steps from https://github.com/webcompat/web-bugs/issues/42962#issuecomment-547346640 (panning doesn't work after zoom-in/out).

So, my case is a bit weird, I could reproduce the issue in non-Nightly Preview and also my own local build of latest m-c, but I could NOT reproduce in Nightly on my phone (even reinstall the application!). I tried another Android phone, the issue is reproducible with same version of Nightly (which makes more sense to me). I have no idea why I could not reproduce the issue in Nightly on my phone.

But also because of that, I could somehow compare the behavior between Nightly and non-Nighly.

Update what I found so far, I saw a difference on pointerup and pointercancel event while zoom-in/out with two finger.

  • in Nightly (which I could NOT reproduce the issue), I got

pointerdown { pointerId: 0, pointerType: touch, pageX: 254, pageY: 421 ... }
pointerdown { pointerId: 1, pointerType: touch, pageX: 56, pageY: 263 ... }
pointerup { pointerId: 0, pointerType: touch, pageX: 236, pageY: 402 ... }
pointerup { pointerId: 1, pointerType: touch, pageX: 120, pageY: 272 ... }

  • but in Non-Nightly, I got

pointerdown { pointerId: 0, pointerType: touch, pageX: 225, pageY: 428 ... }
pointerdown { pointerId: 1, pointerType: touch, pageX: 59, pageY: 162 ... }
pointercancel { pointerId: 0, pointerType: touch, pageX: 225, pageY: 428 ... }

Flags: needinfo?(echen)

(In reply to Edgar Chen [:edgar] from comment #16)

So, my case is a bit weird, I could reproduce the issue in non-Nightly Preview and also my own local build of latest m-c, but I could NOT reproduce in Nightly on my phone (even reinstall the application!).

Err, I did more tests again, I could NOT reproduce in my own local build with latest m-c (This makes more sense, given that I could not reproduce on Nightly, either). And I got follow result from mozregression

12:40.13 INFO: First good revision: 59ecd0b2823006cee80869b744407bfec7de8cd3
12:40.13 INFO: Last bad revision: 77a6b06925100509d1f40190bd1048f6b6f44527
12:40.13 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=77a6b06925100509d1f40190bd1048f6b6f44527&tochange=59ecd0b2823006cee80869b744407bfec7de8cd3

Now I could reproduce the issue in my local build with reverting bug 1602597. Bug 1602597 only affect specific devices which also explains why the issue is still reproducible in Nightly on some Android phone.

See Also: → 1602597

(In reply to Edgar Chen [:edgar] from comment #16)

  • but in Non-Nightly, I got

pointerdown { pointerId: 0, pointerType: touch, pageX: 225, pageY: 428 ... }
pointerdown { pointerId: 1, pointerType: touch, pageX: 59, pageY: 162 ... }
pointercancel { pointerId: 0, pointerType: touch, pageX: 225, pageY: 428 ... }

Ths pointercancel is from https://searchfox.org/mozilla-central/rev/6305f6935f496b3a302c7afcc579399a4217729c/gfx/layers/apz/util/APZEventState.cpp#402

(In reply to Edgar Chen [:edgar] (OO 2019/12/25~2020/01/01) from comment #18)

(In reply to Edgar Chen [:edgar] from comment #16)

  • but in Non-Nightly, I got

pointerdown { pointerId: 0, pointerType: touch, pageX: 225, pageY: 428 ... }
pointerdown { pointerId: 1, pointerType: touch, pageX: 59, pageY: 162 ... }
pointercancel { pointerId: 0, pointerType: touch, pageX: 225, pageY: 428 ... }

Ths pointercancel is from https://searchfox.org/mozilla-central/rev/6305f6935f496b3a302c7afcc579399a4217729c/gfx/layers/apz/util/APZEventState.cpp#402

This intention of that code is to implement the following requirement (from MDN):

The pointercancel event is fired [...] if after the pointerdown event is fired, the pointer is then used to manipulate the viewport by panning, zooming, or scrolling.

In that description, "panning" refers to panning done by the browser itself. I am guessing that on Google Maps, the site prevents the browser from panning itself, and implements the panning logic in the site's code.

That should be handled by the isTouchPrevented condition here: if the site prevents the browser from panning (by calling preventDefault() on the events), then isTouchPrevented should be true, and the block to fire the pointercancel should not be entered.

So, if we are getting an unwanted pointercancel, the thing to debug would be why is isTouchPrevented not being set.

Unfortunately I was unable to reproduce the problem myself on my Moto G5, with or without WebRender.

After some discussion with Ksenia, I was able to reproduce the problem intermittently, with WebRender disabled, if I zoom in on the map before trying to pan (the zooming seems to be important).

I'll see if I can trigger it often enough to get somewhere useful with it.

Interestingly, my intermittent repros do not seem to be correlated with firing pointercancel events (I'm not seeing any pointercancel events fired).

So, in my case, the reason some drags fail is simply that the website content is not handling them (i.e. it doesn't preventDefault() them, which is presumably linked to it not responding to them).

(The reason I'm not seeing a pointercancel in the cases where the site does not preventDefault() the events is that aApzResponse == eIgnore here, but that's the case for successful gestures too, so it's not what's causing this bug.)

The next step here would be to locate the part of the website's code that decides whether or not to preventDefault() touch events, and see why it's not doing that sometimes.

Here is a stack trace for the website calling preventDefault() during a successful gesture:

0 S2(a = "[object TouchEvent]") ["https://www.google.com/maps-lite/js/2/ml_20191211_1/b0b3d/pwa/map_raster.js":24:263]
1 i3/this.T<(d = "[object TouchEvent]") ["https://www.google.com/maps-lite/js/2/ml_20191211_1/b0b3d/pwa/map_raster.js":32:119]
    this = [object HTMLDivElement]

I've additionally noticed that what initially appeared to be an intermittent issue looks like it actually has to do with the position on the gesture on the map: gestures in the bottom half of the map consistently fail, and gesture in the top half consistently succeed.

And now I can't reproduce the issue at all any more. The stack trace for the preventDefault()s has also changed:

0 S2(a = "[object TouchEvent]") ["https://www.google.com/maps-lite/js/2/ml_20191211_1/b0b3d/pwa/map_raster.js":24:263]
1 OFb(a = "[object Object]", b = "[object TouchEvent]") ["https://www.google.com/maps-lite/js/2/ml_20191211_1/b0b3d/pwa/map_raster.js":34:144]
2 NFb/this.W<(e = "[object TouchEvent]") ["https://www.google.com/maps-lite/js/2/ml_20191211_1/b0b3d/pwa/map_raster.js":34:30]
    this = [object HTMLDocument]

Perhaps there's been a change on the site side which fixed the problem?

I'll just add, for completeness, the prior to the behaviour change described in comment 25, my investigation was pointing in the direction of there being an invisible element covering up the bottom half of the map which was eating touch events and preventing them from reaching the listener that would preventDefault() them. However, I wasn't able to confirm this before the site updated and the problem seemed to be resolve itself.

After playing around with it some more, I was able to reproduce again.

When the bug occurs, there is indeed an invisible element covering up the bottom half of the map. The element in question shows up as something like <div class="vLulzM4vR0i__container ml-start-expand-draggable visible"> in the Inspector, and its presence seems to be related to the fact that "Directions" panel is not collapsed completely.

Attachment #9118927 - Attachment description: Directions pane completely hidden ==> but does not occur → Directions pane completely hidden ==> bug does not occur
Attachment #9118927 - Attachment description: Directions pane completely hidden ==> bug does not occur → Directions panel completely hidden ==> bug does not occur

Observe the bottom of the screen (just above the URL bar) in the two attached screenshots:

  • in the first, the top of the "Directions" panel is still visible, and this is causing the bottom half of the map to not be pannable
  • in the second, the "Directions" panel is completely hidden and replaced with a "Tab to see quick actions" bar, and all of the map is pannable

My guess is that the first state is one that the site does not expect to be in, except perhaps in the process of animating the Directions panel offscreen.

What may be happening is that something is interrupting the animation of the Directions panel offscreen, leaving us in this broken state. This is the direction in which I would suggest further investigation.

(In reply to Botond Ballo [:botond] from comment #30)

  • in the first, the top of the "Directions" panel is still visible, and this is causing the bottom half of the map to not be pannable

I found a way to consistent reproduce "Directions panel not completely hidden" on my side: swipe down "Directions" panel and release the touch on URL bar. Here is the video: https://drive.google.com/file/d/1NUEzgteFkzuU1FP7dnYxzENJGcFw9ayq/view?usp=sharing

For google map case, I do not see pointercancel events, either (same as comment 21). What I observe is that there is no pointerup event fired if touch is released on URL bar. I suspect maybe this leaves page in a broken state.

It seems the issue on duckduckgo map is a different one (comment 16), separated it to bug 1607463.

Hmm, I wonder what we do in Fenix with touchend/touchcancel events if one releases touch on top of url bar.

See Also: → 1607463

(In reply to Olli Pettay [:smaug] from comment #33)

Hmm, I wonder what we do in Fenix with touchend/touchcancel events if one releases touch on top of url bar.

There is a touchend event fired.

And if I release touch outside the screen, there is "touchend" event fired, but no "pointerup". Chrome fires both.
I got the same result on Surface Pro.

Assignee: nobody → echen

(In reply to Botond Ballo [:botond] from comment #19)

Unfortunately I was unable to reproduce the problem myself on my Moto G5, with or without WebRender.

My bad, I got confused here. I thought comments 16-19 pertained to Google Maps, but I now understand they pertain to DuckDuckGo maps.

(In reply to Botond Ballo [:botond] from comment #36)

My bad, I got confused here. I thought comments 16-19 pertained to Google Maps, but I now understand they pertain to DuckDuckGo maps.

Thank you for all of the investigation, it is really helpful ;)

(In reply to Edgar Chen [:edgar] from comment #32)

What I observe is that there is no pointerup event fired if touch is released on URL bar. I suspect maybe this leaves page in a broken state.

Correction: there is a pointerup event, but the target is <html>.

Chrome dispatches pointermove/pointerup to the same target where the touch is initiated even when touch moves out of the target, just like touch events. But we dispatch pointermove/pointerup according to the hit test, https://searchfox.org/mozilla-central/rev/be7d1f2d52dd9474ca2df145190a817614c924e4/dom/events/PointerEventHandler.cpp#592-598.

(In reply to Edgar Chen [:edgar] from comment #38)

Chrome dispatches pointermove/pointerup to the same target where the touch is initiated even when touch moves out of the target, just like touch events.

Edge behaves like this, too.

Blocks: 822898

Edgar, this seems to have stalled. Any updates?

Flags: needinfo?(echen)

We need to check how other browsers handle pointermove and pointerup in various cases and maybe fire spec issues to clarify, will get back to this after fission work.

Flags: needinfo?(echen)

(In reply to Edgar Chen [:edgar] from comment #38)

(In reply to Edgar Chen [:edgar] from comment #32)

What I observe is that there is no pointerup event fired if touch is released on URL bar. I suspect maybe this leaves page in a broken state.

Correction: there is a pointerup event, but the target is <html>.

Chrome dispatches pointermove/pointerup to the same target where the touch is initiated even when touch moves out of the target, just like touch events. But we dispatch pointermove/pointerup according to the hit test, https://searchfox.org/mozilla-central/rev/be7d1f2d52dd9474ca2df145190a817614c924e4/dom/events/PointerEventHandler.cpp#592-598.

Okay, I just realized there is a spec change on pointer event for touch, https://github.com/w3c/pointerevents/pull/129. We implemented it in bug 1293174, but disabled by default. I test again with setting dom.w3c_pointer_events.implicit_capture to true, then I don't see this issue anymore.

Depends on: 1669729
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: