Wrong place for selected polygon in print preview

[Maryzandi]

Describe the bug
In print preview it is possible to select a polygon (or area) by clicking on the map while highlighted area after the click, which will be shown in blue color, doesn’t match with selected polygon, i.e. the area that was clicked on the map.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'print preview'
2. Click on a polygon (which is selectable)
3. Another polygon on the map will be selected

Screenshots

Here a property in the map is selected but the selected property is in the wrong place. The property which was clicked is at the corner of the map.

[jokd]

This is a bug and has to do with the dpi setting in the print layout. It also affects scrollzooming and panning the map.

[steff-o]

I have investigated this and it is because the print preview uses transform: scale on the map container. In my opinion it is a bug in openlayers and I have filed an issue there openlayers/openlayers#13283. As a side note, mapbox have had the same issue, but they have fixed the problem (at least some of it): mapbox/mapbox-gl-js#10096

If it is not fixed in OL, it may be possible to create a workaround in origo, but so far I haven't had any success.

One approach would be to try to forego OL by attaching an eventhandler for pretty much all mouse events and calculate where the mouse event should be i OL is to interpret it as where the user wants it to occur and then dispatch a new event at take "fake" location. I have tried this, but without any luck as it seems like OL gets the event before my code. Maybe the handler must be added earlier than just when the print preview is opened.

Another more pragmatic approach would be to only fix the featureInfo/marker problem by doing the calculation after OL already has dealt with the event, i.e. by trying to calculate the correct position in featureInfo.onClick(). This would not fix the zoom wheel scroll and pan issues, but those still work, albeit not very nice.

[steff-o]

After posting the issue in OL I have received another possible solution in that issue. In advent of a fix in OL we can add a monkey patch that replaces a function i OL. This way we would fix pretty much all problems except pan and pinch zoom (which could probably be fixed with another monkey patch...). But it could be risky as it may not be chosen for development i OL and then we are stuck with our monkey patch.

I have tried the monkey patch approach and it works, but to to on the safe side I only added it in the print component and restore it when print component closes. I have not written a PR on this, as I'm not convinced that monkey patching is what we want.

[jokd]

Well if that what it takes then I'd say we go for it and keep an eye on the OL ticket.