Wrong mouse position on RTL pages on Webkit

[n0nick]

This is the same behaviour described in #1665, but seems to be caused by the fix for webkit on DomEvent.js.

Reproduced here:
http://jsfiddle.net/n6sZW/
The body is RTL, and so on webkit the mouse position reported is false. Evidence can be seen by clicking on the map and the popup appears at the perceived (false) mouse position.

Overriding documentIsLtr to always return true fixes this:
http://jsfiddle.net/XSaFU/1/
In this example, clicking on the map shows the popup at the correct place, implying mouse position is correct.

Is the webkit fix on DomEvent.js still relevant?

[fastrde]

Tested with Chrome Version 28.0.1500.95 (MacOS),
Safari Version 6.0.4 (8536.29.13) (MacOS) and
Firefox 22.0 (MacOS)

In Chrome and Safari (both Webkit) i get the false mouse position.
When I delete the L.Browser.webkit check in function L.DomEvent.getMousePosition it works correctly.
Here is a version with no webkit-check to test in your browser.

http://www.fastr.de/tests/leaflet-rtlfix.html

[danzel]

Have given this a test, looks like it isn't needed anymore. Weird that the OSM guys haven't reported anything about this as it would likely affect them.
The same check is in https://github.com/Leaflet/Leaflet/blob/master/src/dom/DomUtil.js#L83

@jfirebaugh any thoughts here? Heard anything?

[mourner]

Probably doesn't affect OSM because its RTL layout puts the map in 0, 0 position.

[mourner]

So, what are we doing with this? Simply removing the webkit condition can break previously fixed older webkit implementations (like some Android versions), perhaps we should search for the bug in Webkit Bugzilla and find out what version fixed it, and are there any tricks for detecting the need for the workaround without browser sniffing.

[mourner]

Still not sure what to do with this... @danzel thoughts?

[n0nick]

@mourner do you have a webkit/chrome version where you know this fix was required? we could bisect from there...

[danzel]

This should be broken with whatever was the current chrome at 2012-10-28
ref #1099 #1100

[n0nick]

Last stable Chrome version before that date is 22.0.1229.94
according to: http://googlechromereleases.blogspot.co.il/2012_10_01_archive.html

[mourner]

@danzel I'm just wondering if it can affect other WebKit browser like Android too. But maybe we should just remove the hack and see if anyone has problems again.

[danzel]

I'm getting an old chrome version atm
http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?path=Win/
Just slowly working out which rev :)

[danzel]

Good news: It's in the wrong place in old chrome too!
using http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?path=Win/149138/
and http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?path=Win/163259/
They both have the same issue. Fixing now...

ie 8 regressed in
0c38132
4 months ago (Sat Jul 06 03:50:36 2013)

[danzel]

I've created some test pages and sort of fixed it (by deleting all our rtl code)
https://github.com/danzel/Leaflet/tree/rtl

The old code worked well until 0c38132.
Since then the rtl code is unneeded EXCEPT in IE 9/10/11 where if you load debug/tests/rtl.html, resize it to not fit horizontally, scroll the page part way, click on the map; the created popup will be in the wrong place.