Follow GPS position doesn't always correctly disengage

[RubenKelevra]

I noticed that the "follow GPS position" function doesn't always disengage quickly, if the user is panning away. This leads to a "snapping" back to the GPS position, which is unexpected.

Screenshot

InShot_20240821_152823011.mp4

How to Reproduce

• Engage GPS following
• Pan away
• GPS following does not turn back to black and stays engaged
• on next GPS update the map will snap back to the GPS position

Expected Behavior
GPS following should disengage as soon as the user moves the map around.

Versions affected
Android 12
SC 59.0 Alpha 1

[Helium314]

The problem is here.
MapLibre calls onMoveBegin even when there was no move, so the workaround for checking whether there was an actual move is necessary to separate moves from taps. This has the side effect of not registering a move when you tap the map, hold for a while and then move.

[RubenKelevra]

Okay? 🤔

Is there no way to hook something different to get the actual viewpoint updates? If so you could compare if the new center of the viewpoint is roughly the GPS position.

[Helium314]

I thinks this should actually be fixed on MapLibre side. onMoveBegin being called without move is very unexpected.

[westnordost]

True, but they are really slow in fixing bugs. So it would be good to have a (better working) workaround until then. Has it been reported already?

[westnordost]

@Helium314 do you have another idea how to workaround this issue? If not, we should just create an issue at MapLibre and close this one. (And if yes, we should implement that workaround and still create an issue at MapLibre.)

[RubenKelevra]

If not, we should just create an issue at MapLibre and close this one.

I recommend keeping persistent issues open, even if not actionable. It makes sure that nobody else invests time to create a bug-report which then just gets closed as duplicate.

See #5572, #5699, #5651, #5584

[matkoniecz]

well, people should anyway look also at matching closed ones before reporting

[RubenKelevra]

Why? Github discourages this by only searching for open issues by default and if a bug is closed its either "completed" or "won't fix":

Both don't apply to not yet fixed bugs.

[westnordost]

Reported upstream but also found a workaround that might work.

[RubenKelevra]

Will test it as soon as I can start the app again, thanks!

[mnalis]

Will test it as soon as I can start the app again, thanks!

the workaround should be included in v59.0-alpha4 @RubenKelevra so feel free to test it when you have an intermezzo between breaking them 🥲

[RubenKelevra]

@mnalis can confirm, workaround works like a charm in 59 alpha 4 :)