Controls misbehave in WebKit browsers when vector layers present and map is rendered

[Nick M]

This bug is present in both Safari 4.0.4 (Mac) and Chrome 4.0.249.43 (Mac).

If you initialize a Map object without passing a div to the constructor, and then later call map.render("map_div"), a number of oddities crop up when vector layers are used. I've attached an example page that demonstrates the bug, but basically it looks like mouse events aren't being properly handled. If you try to drag or pan the map around, the base layer will move, but the vector layer stays put. Additionally, it looks like other controls won't work. If I try to select the zoom or measure tools in our application, those tools don't work. Instead, the map keeps responding as if I were panning (with the base layer moving, and the vector layer staying put).

I've attached a patch with what I've found to be a solution. By appending the div to the document that's created when a div isn't supplied to the Map constructor, that seems to work. I'm not entirely sure if this is the best solution, but it seems to fix all these issues with vector layers and calling render() later on a map.

A few other notes:

* If I have a vector layer and a WMS layer on the map simultaneously, then the vector layer beings behaving. * If I use the Open Street Map layer as a base layer, instead of any Google layer, then the vector layer also beings behaving.

[bartvde]

This does not seem a regression to me, so bumping for now. Please move back to 2.9 if you think this is a regression from 2.8.

[elemoine]

I created webkit_bug_2.html because the sphericalMercator must be used when using a Google Maps layer and a vector layer.

But even when using sphericalMercator I don't see the same behavior on Chromium as on FireFox. In Chromium (and probably all webkit-based browsers) if render() is called after zoomToMaxExtent the map isn't rendered. And Nick M's patch does solve the issue. I'm curious to know what others think about this patch.

[elemoine]

with sphericalMercator:true

[crschmidt]

I'm fine with this patch. I think we should make the webkit2.html example a manual test. We can also document that people can't touch the automatically created map div and expect their changes to stick around, but I can't imagine that's a serious problem anyway. I'd like to see someone ensure that the GeoExt functionality (examples )and tests pass with this patch applied though, since I think that GeoExt is much more likely to expose flaws in this patch than anything else in the OpenLayers examples/tests.

[erilem]

Replying to crschmidt:

I'm fine with this patch. I think we should make the webkit2.html example a manual test. We can also document that people can't touch the automatically created map div and expect their changes to stick around, but I can't imagine that's a serious problem anyway. I'd like to see someone ensure that the GeoExt functionality (examples )and tests pass with this patch applied though, since I think that GeoExt is much more likely to expose flaws in this patch than anything else in the OpenLayers examples/tests.

Taking care of that right now.

[erilem]

The GeoExt tests pass with the patch applied. And the examples seem to work.

I think it would make sense to reference this ticket in the code, so we can easily recall why we're doing things this way.

Thanks Chris, please commit.

[crschmidt]

(In [11645]) "Controls misbehave in WebKit browsers when vector layers present and map is rendered"; this fix was presented by Nick M, and reviewed by erilem. (Closes #2392)

[ahocevar]

The above fix is voodoo and breaks existing applications. Providing a new patch.

[ahocevar]

The above patch makes the attached example work. Relevant tests still pass. Thanks for any review.

[bartvde]

Thanks Andreas, this looks good, I've confirmed the manual test page to work fine now, and tests pass in Safari as well. Please commit.

[ahocevar]

(In [11697]) reverting r11645, and fixing the root of the reported problem. r=bartvde (closes #2392)