Track popup to cursor [ready]

[peterqliu]

ticket: #7777

Adds a method .trackPointer() to the Popup API that repositions the popup to the mouse cursor on every mousemove event, and hides/shows the popup when cursor leaves/enters the map. Mutually overwritable with .setLngLat.

Design

Opted not to extend setLngLat, as it doesn't quite fit those words. Also opted not to extend the popup options object, for cases when users need to change behavior after adding to map.

Launch Checklist

• briefly describe the changes in this PR
• write tests for all new functionality
• document any changes to public APIs
• manually test the debug page
• tagged @mapbox/studio and/or @mapbox/maps-design if this PR includes style spec changes

[ryanhamley]

Touchscreen behavior: show popup only on touchmove? Not show at all? Console warning when invoking .trackCursor() on touch devices?

I'm trying to imagine a use case for this on mobile. It seems like it would be a very awkward UX as compared to simply touching on each new point to see a new popup. On the other hand, having a desktop only API method seems odd. Do we have other methods that don't work on mobile? If we do enable this on touchmove, maybe it would be better to call the method a more generic term like trackPointer.

Close button: won't be clickable when popup shadows mouse. Should we hide? Does that affect any corner cases?

This is a fun consequence. Maybe there needs to be a separate action to close the popup in this case. Would clicking the map to toggle the popup be too weird?

[peterqliu]

Mobile handling

In lieu of hover, I thought about adding cursor-tracked popups to a tap on the map. The interaction pattern for mobile is unfortunately quite complex: click is the event that typically corresponds to this, but is nondeterministic. On Webkit browsers where the user has also implemented a hover listener, click is invoked only on the second tap, and not a double-tap at that. Because of this unpredictability, I've removed touchscreen support entirely for pointer-tracked popups, until we can implement a more deterministic behavior given underlying browser constraints.

Other changes

• renamed trackCursor to trackPointer, to reflect the mouse-specific compatibility
• move the show/hide logic to CSS, greatly simplifying the event handler logic
• opted to keep the closeButton by default, as is the current Popup default. The change is easy enough on the user's side

[KravMaguy]

Mobile handling

In lieu of hover, I thought about adding cursor-tracked popups to a tap on the map. The interaction pattern for mobile is unfortunately quite complex: click is the event that typically corresponds to this, but is nondeterministic. On Webkit browsers where the user has also implemented a hover listener, click is invoked only on the second tap, and not a double-tap at that. Because of this unpredictability, I've removed touchscreen support entirely for the time being.

Peter If you remove the touchscreen support how can we show the user information about the
individual rooms in the building on mobile? will I loose the tooltip functionality in this example on mobile:
https://codepen.io/kravmaguy/pen/zerMJx

[peterqliu]

@KravMaguy that is correct, you will lose that functionality if you use a cursor-tracked popup on mobile. In these contexts, most apps display the information in a panel separate from the map: it's a much better practice given the limited screen space, and preserves visibility/interactivity of the map itself.

some examples ⬇️

[peterqliu]

@KravMaguy you can still unproject/setLngLat the popup on each touch event, to move the popup there

[ryanhamley]

I think overall it looks fine but I think the behavior is a little odd.

• If you move the mouse quickly enough, you can end up inside the popup. I'm not entirely sure what the answer here could be, if anything.

• The cursor partially obscures the "spout" of the popup when it's top-aligned. Perhaps we should add a bit of padding to the cursor to move it down a bit and/or make the cursor into a pointer instead of the grabber hand.

• If you pan the map, the popup stays in one spot. Maybe on pan, the popup should close? I could see that being unexpected though.

[peterqliu]

If you pan the map, the popup stays in one spot. Maybe on pan, the popup should close? I could see that being unexpected though.

👍the popup should definitely follow the cursor

If you move the mouse quickly enough, you can end up inside the popup. I'm not entirely sure what the answer here could be, if anything.

Unfortunately this looks like a limitation of the browser, in that it emits mousemove events too slowly to keep up with the mouse's actual movement. Not sure if we can do anything here

The cursor partially obscures the "spout" of the popup when it's top-aligned. Perhaps we should add a bit of padding to the cursor to move it down a bit and/or make the cursor into a pointer instead of the grabber hand.

Agree that this is weird, but the specific solution seems like it would vary by user/use case/preference. I'm inclined to let people modify CSS as appropriate.

[ryanhamley]

Agree that this is weird, but the specific solution seems like it would vary by user/use case/preference. I'm inclined to let people modify CSS as appropriate.

👍 I do think it makes sense to change the cursor from a grabber to a pointer when in trackPointer mode. The idea of this feature is to point at various locations on the map and get information about them, so the pointer feels semantically valid as well as it visually covering less of the popup.

[peterqliu]

• opted to hide popup when dragging the map -- tracking popup on drag made it harder to see the map when repositioning it takes priority

• cursor is now pointer when tracking popup

[peterqliu]

If you move the mouse quickly enough, you can end up inside the popup. I'm not entirely sure what the answer here could be, if anything.

Also removed interactivity with pointer-tracked popups, to avoid getting trapped in it 👍

[Plantain]

Is this likely to make it into a release in the near future? We'd like to use this feature rather than the workarounds in #7777

[peterqliu]

@Plantain this branch is ready to the extent that I can tell -- looping in some reviewers to see if we can get this across the line.

[ryanhamley]

Couple minor things but this looks good to me

[ryanhamley]

This is too late to be in the next release of GL JS which comes out this week, but it should be in May's release

[peterqliu]

clarified a bit of the code per #7786 (comment) and squashed as much as I can (not sure if I can squash past a previous pull from master?)

[ryanhamley]

You don't have to squash ahead of time @peterqliu. Once all the checks have passed, just pressing the Squash and merge button will take care of everything. You'll see a text field with the previous commits listed as a description. I usually just delete everything in that field and make sure the commit message is descriptive.