[Search Map] Enable preserve a specified URL zoom parameter on page load (Tech migration)

[DieBatzen]

Enables #2545 after GS tech update.

[2Abendsegler]

@DieBatzen
Moin,
great that you're continuing to work on the search map.
I've opened the new issue #2708 where we can coordinate the work on the search map. Please send a short message there in the future if you take on any of the work so that we don't do anything twice.
I've registered you there for the function setZoom.

[DieBatzen]

As usual, an unexpected issue showed up. :(
This time, FF behaves slightly different than Chrome. Even worse, one day before it didn't - at least it wasn't observable ...
Long story short, now the code works in both, FF and Chrome.

PR is now ready for merge.

[DieBatzen]

@DieBatzen Moin, great that you're continuing to work on the search map. I've opened the new issue #2708 where we can coordinate the work on the search map. Please send a short message there in the future if you take on any of the work so that we don't do anything twice. I've registered you there for the function setZoom.

Good idea.
I'll add a comment there if and before I'm taking over a task.
And hopefully we didn't overlap on this task here ...

By the way, assignment for setZoom got somehow swapped with scrollInCacheList.

[2Abendsegler]

@DieBatzen
Moin,
I haven't tested yet.
I can't really reproduce it right now. Maybe I just don't understand what it's about. For example, if I select the Search geocaches button on the Browse Map, I get to the Search Map. There the zoom parameter is always set to 11, regardless of what was previously passed on via the url. From my point of view, the passed zoom parameter is ignored, but is not set to 14 but to 11.

Maybe we should continue to only execute unsafeWindow.MapSettings.Map.setZoom(zoom); if a zoom parameter was passed.

In the current version it said

if (zoom !== 14) {
    unsafeWindow.MapSettings.Map.setZoom(zoom);
}

[DieBatzen]

@DieBatzen Moin, I haven't tested yet. I can't really reproduce it right now. Maybe I just don't understand what it's about. For example, if I select the Search geocaches button on the Browse Map, I get to the Search Map. There the zoom parameter is always set to 11, regardless of what was previously passed on via the url. From my point of view, the passed zoom parameter is ignored, but is not set to 14 but to 11.

It's more dynamic.
The zoom level that GS uses on the search map depends on where you perform the search.
E.g. https://www.geocaching.com/map/#?ll=60.08186,7.42225&z=15 (zoom=15) on browse map gives https://www.geocaching.com/live/play/map?sort=distance&asc=true&st=N+60%C2%B0+04.912%27+E+7%C2%B0+25.334%27&lat=60.0818666666667&lng=7.42223333333333&ot=coords&r=16&zoom=18 (zoom=18) on search map.

In another area, https://www.geocaching.com/map/#?ll=52.52735,13.41185&z=15 (zoom=15) on browse map gives https://www.geocaching.com/live/play/map?sort=distance&asc=true&st=N+52°+31.641'+E+13°+24.710'&lat=52.52735&lng=13.4118333333333&ot=coords&r=16&zoom=13 (zoom=13) on search map.

The first example has low cache density, the second has high cache density. It looks like the number of resulting caches, together with the search radius of 16km (r=16) from the URL, determines the zoom level.

Maybe we should continue to only execute unsafeWindow.MapSettings.Map.setZoom(zoom); if a zoom parameter was passed.

In the current version it said

if (zoom !== 14) {
    unsafeWindow.MapSettings.Map.setZoom(zoom);
}

In the actual code, if (zoom !== 14) { is already skipped. unsafeWindow.MapSettings.Map.setZoom(zoom); will be executed with the supplied zoom level or, if none given, with 14 (which seems to be a reasonable zoom level giving a good map overview).

[DieBatzen]

During investigation of your remarks, another (mean) issue in FF showed up:
sometimes the zoom parameter gets altered more than once which results in an undesired final zoom.

This is now also taken into account in the code and the branch is force-pushed with the changes.

[2Abendsegler]

Moin.

I didn't know that GS determines the zoom parameter based on the cache density. That's not uninteresting.

I've given our feature some thought.

With our feature we want to ensure that a specified zoom parameter is applied and not changed by GS.

If no zoom parameter is specified, we shouldn't just set any meaningful zoom parameter. In such a case, GS should set the zoom parameter. In my view, it makes sense that GS sets a different zoom parameter when the cache density is high than when the cache density is lower. Of course, you can also prefer a zoom parameter at a fixed height. The height is probably judged differently. But... that would be another, different feature. Our feature should only be about applying the specified zoom parameter.

A little bug: With the current coding, an URL without a zoom parameter (https://www.geocaching.com/play/map) is always adjusted to 14 when you zoom in or out. So you can't get away from 14.

Can you please think about the feature again?

[DieBatzen]

If no zoom parameter is specified, we shouldn't just set any meaningful zoom parameter. In such a case, GS should set the zoom parameter. In my view, it makes sense that GS sets a different zoom parameter when the cache density is high than when the cache density is lower. Of course, you can also prefer a zoom parameter at a fixed height. The height is probably judged differently. But... that would be another, different feature. Our feature should only be about applying the specified zoom parameter.

I don't have a strong opinion about that "meaningful zoom parameter" and am perfectly fine with skipping it.

The main idea was to prevent e.g. initial views with quite small zoom level, such as zoom=10 when calling the default link to search map https://www.geocaching.com/live/play/map (at least with our home coordinates).
But I agree, let GS handle the cases where no zoom level was specified.
Will adapt the code accordingly.

A little bug: With the current coding, an URL without a zoom parameter (geocaching.com/play/map) is always adjusted to 14 when you zoom in or out. So you can't get away from 14.

It's rather a feature than a bug. ;)
If you wait shortly after page load, then zooming works as expected.
Reason is this code part in setZoom():

// There are cases in FF where zoom level in URL alters more than once.
// Therefore, allow to correct multiple times, then disable after some time period.
setTimeout(() => { use_zoom_from_url = false; }, 5000);

That's the only reliable solution I could come up with that works in both, Firefox and Chrome in all cases.
We simply react on all zoom changes (triggered by GS) for a short period of time (5s, starting from the first zoom change), otherwise our changed zoom level could get reset by multiple GS URL changes.

The only downside of this approach is what you observed: if you zoom in/out very shortly after page load, you might notice that the zoom level stays as it is ... and that resolves itself, on some of the next tries.

Maybe a reasonable solution is to simply disable the zoom buttons for this time period?

Can you please think about the feature again?

Done. ;)

[2Abendsegler]

The main idea was to prevent e.g. initial views with quite small zoom level, such as zoom=10 when calling the default link to search map

Yes, I see it the same way. We can perhaps implement this in a variable form on another occasion, so that the user can specify the zoom parameters themselves.

A little bug: With the current coding, an URL without a zoom parameter (geocaching.com/play/map) is always adjusted to 14 when you zoom in or out. So you can't get away from 14.

It's rather a feature than a bug. ;) If you wait shortly after page load, then zooming works as expected. Reason is this code part in setZoom():

// There are cases in FF where zoom level in URL alters more than once.
// Therefore, allow to correct multiple times, then disable after some time period.
setTimeout(() => { use_zoom_from_url = false; }, 5000);

You're right. I thought it would be longer, but I can't reproduce that.

[2Abendsegler]

Ich noch mal. :)

Ich habe noch etwas mehr getestet mit übergebenem Zoom Parameter. Die Wiederholung von 5 Sekunden empfinde ich als ziemlich störend. Wenn ich das Mausrad mit dem Zoom bewege fährt die Karte quasi mehrfach rein und raus. Auch wenn ich die Karte verschiebe, wird sie innerhalb der Zeitspanne wieder zurück geschoben. Und manchmal wird zwischendurch auch wieder auf die Zoom Stufe von GS zurückgesetzt, vermutlich durch GS. Andererseits möchte ich auch nicht 5 Sekunden warten bis ich loslegen kann.

Wenn man die 5 Sekunden wegstreicht und die Zoom Stufe nur einmal setzt, so wie es früher wohl mal funktioniert hat, landet man in einigen Fällen nicht auf der beabsichtigten Zoom Stufe. Da hast du völlig recht. Ich habe das jetzt in Firefox auch einige Male gesehen.

Ich habe dieses Feature ganz anders in Erinnerung. Eben ohne das ganze Gezucke.

Ich glaube nicht, dass es so wie es jetzt abläuft Sinn macht. Wir müssen die Implementierung dieses Feature nicht erzwingen. Wenn wir keine akzeptable Lösung finden, dann ist das halt so. So was kommt vor.

Wenn dir nichts mehr einfällt, dann stell es einfach zurück, vielleicht hast du irgendwann später noch eine Idee. Oder vielleicht fällt auch jemand anderem noch was ein. Mir vermutlich eher nicht, dafür habe ich viel zu wenig Ahnung. Oder wir vergessen das Feature. Was nicht geht, geht nicht.
Was meinst du?

[DieBatzen]

Ich noch mal. :)

Ich habe noch etwas mehr getestet mit übergebenem Zoom Parameter. Die Wiederholung von 5 Sekunden empfinde ich als ziemlich störend. Wenn ich das Mausrad mit dem Zoom bewege fährt die Karte quasi mehrfach rein und raus. Auch wenn ich die Karte verschiebe, wird sie innerhalb der Zeitspanne wieder zurück geschoben. Und manchmal wird zwischendurch auch wieder auf die Zoom Stufe von GS zurückgesetzt, vermutlich durch GS. Andererseits möchte ich auch nicht 5 Sekunden warten bis ich loslegen kann.

Wenn man die 5 Sekunden wegstreicht und die Zoom Stufe nur einmal setzt, so wie es früher wohl mal funktioniert hat, landet man in einigen Fällen nicht auf der beabsichtigten Zoom Stufe. Da hast du völlig recht. Ich habe das jetzt in Firefox auch einige Male gesehen.

Ich habe dieses Feature ganz anders in Erinnerung. Eben ohne das ganze Gezucke.

Ich glaube nicht, dass es so wie es jetzt abläuft Sinn macht. Wir müssen die Implementierung dieses Feature nicht erzwingen. Wenn wir keine akzeptable Lösung finden, dann ist das halt so. So was kommt vor.

Ja, da hast du recht.
Die erzwungene Verzögerung stört mehr, als dass das Feature einen Mehrwert bringt.

Wenn dir nichts mehr einfällt, dann stell es einfach zurück, vielleicht hast du irgendwann später noch eine Idee. Oder vielleicht fällt auch jemand anderem noch was ein. Mir vermutlich eher nicht, dafür habe ich viel zu wenig Ahnung. Oder wir vergessen das Feature. Was nicht geht, geht nicht. Was meinst du?

Eine letzte Idee habe ich noch:
keine permanente Anpassung des zooms während eines fixen Zeitraums 5s, sondern nur bei Bedarf.

Das hat in meinen Tests bisher gut funktioniert (Chrome sowieso, aber auch in FF) und könnte eine Lösung sein.
Ich werde das noch etwas weiter testen und wenn die Lösung stabil bleibt, den PR aktualisieren.

Ansonsten stellen wir das Feature erst einmal zurück.

[2Abendsegler]

Ja, hört sich super an!

Hast du eine Idee warum es unter Firefox diese Probleme gibt? Verursacht das Firefox selbst oder ist eher GS dafür verantwortlich?

[DieBatzen]

Hast du eine Idee warum es unter Firefox diese Probleme gibt? Verursacht das Firefox selbst oder ist eher GS dafür verantwortlich?

Ja, die habe ich tatsächlich. :)
In FF ist die Seite bereits geladen, bevor der gclh anspringt - in Chrome noch nicht, das macht den Unterschied aus.
Das ist im Debugger-Screenshot gut zu sehen: oben der FF, unten Chrome, jeweils am selben Haltepunkt:

Soweit ich das sehen kann, liegt dieser Unterschied an Tampermonkey.
Man kann den Scripts in Tampermonkey mitgeben, wann sie starten sollen, z.B. mit // @run-at document-end.
Gibt man nichts an, dann verwendet Tampermonkey (laut Doku) // @run-at document-idle, was beim gclh der Fall ist.
Und hier verhält sich Tampermonkey nicht so, wie in der Doku beschrieben:
in FF startet der gclh mit // @run-at document-idle (Seite ist bereits geladen, wenn gclh anspringt), in Chrome mit // @run-at document-end (Seite noch nicht vollständig geladen, wenn gclh anspringt).
Das ist auch nicht auf die Seiten von GS oder den gclh beschränkt, sondern lässt sich mit einem Testskript auf beliebigen Seiten nachvollziehen.

Somit wäre die "einfachste" Lösung, dem gclh ein // @run-at document-end im Header mitzugeben.
Dann verhalten sich FF und Chrome gleich und das Feature funktioniert bestens (bereits getestet).
Man müsste dann noch prüfen, dass das keine Auswirkungen auf andere Funktionen hat.
Andererseits läuft der gclh ja auf Chrome (der mit // @run-at document-end startet) problemlos, sollte dann "eigentlich" auch auf FF keine Probleme geben.

Alternativ scheint die gestern erwähnte Lösung stabil zu laufen, könnte daher auch eine Option sein.

[DieBatzen]

Eine letzte Idee habe ich noch:
keine permanente Anpassung des zooms während eines fixen Zeitraums 5s, sondern nur bei Bedarf.

PR entsprechend aktualisiert.

[2Abendsegler]

Vielen Dank für die ausführlichen Informationen!

Somit wäre die "einfachste" Lösung, dem gclh ein // @run-at document-end im Header mitzugeben.

Ich habe mir das angesehen. Das hört sich echt super an, auch wenn wir damit Gefahr laufen, dass etwas nicht mehr richtig funktioniert. Ich schätze mal die Wahrscheinlichkeit dafür ist nicht allzu groß.

Vorschlag:
Du könntest dir deine letzten Änderungen im PR irgendwo aufbewahren, für den Fall dass wir doch wieder zurück müssen. Dann könntest du alles vereinfachen und das // @run-at document-end einbauen.

Was meinst du?

[DieBatzen]

Vorschlag: Du könntest dir deine letzten Änderungen im PR irgendwo aufbewahren, für den Fall dass wir doch wieder zurück müssen. Dann könntest du alles vereinfachen und das // @run-at document-end einbauen.

Was meinst du?

Gute Idee.
Die letzte funktionierende Version mit // @run-at document-idle im FF liegt in meinem Fork als Branch dort:
Version @run-at document-idle

Dieser PR und Branch ist nun force-pushed mit // @run-at document-end im Header und den entsprechenden Anpassungen im Code.
Läuft in Chrome und FF bei mir völlig problemlos.

Ich nehme den Draft-Status wieder raus und falls alles passt, kannst du ja mergen.

[2Abendsegler]

Super, scheint zu passen!