iOS: modify route creates additional point

[zstadler]

Bug

What really happened

When using drag to create a new point along an existing route on an iOS device, the result route has two new points: one point where the drag started and another point where the drag ended.

What I did that caused the issue - step by step

• Create a new route with just a start and end points
• Drag a from any point along the route to a new location

My environment

• Operating System and version: iOS
• Web Browser and version: App

[HarelM]

I've tested this on iOS 15.0 and this issue does not exist.
When upgrading to iOS 15.4 the issue appears.
This is probably not related, but might show on a general problem with 15.4 version:
https://developer.apple.com/forums/thread/703648
It's says in the end that 15.5 RC 2 seems to solve this, so It might be better to wait a bit for the releases before jumping into trying to solve this...

[HarelM]

I've checked the console log for the above related errors and it doesn't seem to be related.
I've also added some console log to try and better understand this issue.
What I see is basically a click I did not make that happens shortly after drag end is finishing the execution in the place where I started the drag.
I'm not sure If I should keep a variable letting me know when was the last time a click was completed and ignore clicks that are "too fast" or open a ticket for iOS.
It seems that this happens more often if I "long press" before starting the drag operation, i.e. click and not move my finger for a few seconds and only after that move it to the desired location.

[HarelM]

I've looked even deeper into this and I see that the following events are fired:

1. touchstart
2. touchend
3. mousedown
4. mouseup

This happens when I long click, it doesn't have to be a mid route point - i.e. simpler reproductions:

1. delete all routes
2. click the pencil to start edit
3. long click on the map
4. --> instead of only the green point appearing there are now two points the green and the red one on top of the other.
   This doesn't happen on safari mobile, and on android.

The preventDefault() should've handled this, but it doesn't for some reason...
I've also tried to create a very simple maplibre-gl cordova app to try and reproduce this, but it doesn't reproduce for some reason :-(

[HarelM]

Further investigation reveals this is related to a plugin we use, I opened an issue with it:
ionic-team/cordova-plugin-ionic-webview#670
But looking at the code of the plugin, this seems like a configuration of the webkit or something so I don't have high hopes there...

[HarelM]

The issue in the linked branch is solved.
The drawback is that the data stored is not passed across the update.
There's still an issue with the animation images in android, but overall everything else seems to be working as expected.

[HarelM]

Changes that needs to be tested before this can be released (iOS, Android, Web):

• GPS icon is visible
• POI animation for empty image POIs
• Fonts and icons are loading well on the map
• Mobile only - Sound for when you do not follow a route
• Mobile only - Offline map can be seen well

[HarelM]

There's a question whether the following issue will also create a situation where users will loose their local storage: #1698. Since this issue exists for some time now, I prefer to keep it open just a bit longer in order to avoid all users loosing their data due to the fix proposed here.
I'll try and see how complicated it is to solve #1698 in order to do it in one go.

[HarelM]

Another direction is to try and use the same scheme and hostname used in ionic-webview.
Android:

    <preference name="scheme" value="http"/>
    <preference name="hostname" value="localhost"/>
    <allow-navigation href="http://localhost/*"/>

And this part:
http://www.javawenti.com/?post=311176 - i.e. replace type='module' with type='text/javascript' in index.html.
iOS:

    <preference name="iosScheme" value="ionic"/>
    <preference name="hostname" value="localhost"/>

and the following edit for iOS only in file.service:
return (window as any).WkWebView.convertFilePath(this.fileSystemWrapper.applicationDirectory + "www/" + relativePath);

This is still not running properly, so I'm not even sure it will keep the data, but if this direction is possible, it's a lot smaller than migrating to Capacitor...

[HarelM]

This will be fixed by migrating to Capacitor. #1698

[HarelM]

Fixed by #1743