Properly calculate the y position of the element when parent is positioned relatively

[jec006]

An attempt to deal with #1744 - this adds in calculation for the top offset when the item is positioned relative. This fixes an issue with mouse events not getting the correct lat/lng when a parent of the map had a vertical offset.

[Camwyn]

In trying to implement this on my site, I found to get the (default) pin to place properly, I had to comment out line 3276 (in leaflet-src.js) like so:
if (anchor) {
img.style.marginLeft = (-anchor.x) + 'px';
//img.style.marginTop = (-anchor.y) + 'px';
}

The latlng appeared to be correct, but the pin placement was off...

The above made the positioning better, but the default pin was still not placed right - went from too low (south) to too high (north). FWIW, this is in a WP admin interface within nested position:relative elements.

[mourner]

@jfirebaugh hey John, can you take a look at this issue? It's related to your earlier PR.

@Camwyn that's quite weird, and commenting the anchor is definitely not the right solution here... Can you set up a JSFiddle that shows the marker problem?

[jec006]

I've made 2 jsfiddles to demonstrate the issue and then the pull request code fixing it (for my use case):

This one: http://jsfiddle.net/jec006/Q4Wpn/ shows the issue with the offset occurring using the current master leaflet-src.js

This second one: http://jsfiddle.net/jec006/UVqWM/ is using the code with the change from this pull request and the markers appear in the correct position.

@Camwyn perhaps you can fork the second one to demonstrate the issue you're still having?

[Camwyn]

I did fork the second, but placing the entire wordpress admin page in jsfiddle seems a bit...awkward.

I'll try to replicate tonight to demo for you - I'll try to match position and style as close as possible.
In the end I managed to fix it by removing position:relative from one of the parent elements.

[mourner]

@Camwyn you don't need to replicate the style as close as possible, just try to create the most simple and minimal test case where the problem is reproducible.

[mourner]

I'll merge the pull, but lets see if we can find a better solution for this that replaces the whole looped code — it has grown to be too complex and potentially has performance implications, so perhaps we should investigate more (e.g. try applying the D3.js approach).

BTW I it's @scooterw that made the original fix, not @jfirebaugh. @scooterw could you take a look at this?

[scooterw]

I see this is closed now. Sorry I didn't see this sooner. Do you still want me to take a look at it, or does this merged PR fix the issue satisfactorily? I apologize for breaking the scrollwheel functionality / mouse events. For some reason, I did not notice this when I was testing out the commit that broke it.

[mourner]

No worries :) Just wanted to check if the fix looks good to you, since you're familiar with this part of the code now.

[lubberscorrado]

Well, to be honest this fix still need a bit of adjusting. When i now point to the anchor of a marker and use mousewheel the marker position is not exactly positioned to the anchor anymore. The marker moves a bit away the more i use the zooming functionality. This was not the case before #1744. Before #1744 the postion was everytime exactly accurate.

[mourner]

@lubberscorrado please provide a JSFiddle every time you point out a bug or a regression.

[brunob]

Hi @mourner i'm also encountering this bug with Leaflet in SPIP backend. Here is a simple fiddle that show the offset generated :

http://jsfiddle.net/8CMjZ/4/

This bug is the last thing that stop me to put Leaflet 0.6.x in GIS plugin for SPIP, hope we'll manage to find a fix :)

[scooterw]

@brunob, @mourner - A couple of things seem to be going on here. Adding r.top to the top value does not appear to be necessary. Commenting out that line and zeroing out the margin on body, div, and h1 elements seems to put the point back in the proper place. It seems to add some combination of margin values if the parent is positioned relative. I would not expect everyone to zero their margins, so this will likely need to be accounted for in some way (if this is indeed part of the problem). I have not figured out a satisfactory solution to this, so if anyone has ideas, or thinks I may be barking up the wrong tree, please let me know.

[gpbl]

There's a similar issue by setting the padding:
http://jsfiddle.net/ZXDkF/3/
#1826 seems to solve the problem to me