ZachPhillipsGary / google-maps-utility-library-v3

Automatically exported from code.google.com/p/google-maps-utility-library-v3
Apache License 2.0
0 stars 0 forks source link

MarkerClusterer cluster/marker display not reliable in Safari #140

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Demo link or sample code:
This can be demonstrated using Google's own demo page:
http://google-maps-utility-library-v3.googlecode.com/svn/trunk/markerclusterer/e
xamples/advanced_example.html
This issue manifests in Safari, but not Firefox.

What steps will reproduce the problem?
1. View a map using MarkerClusterer in which several clusters are available 
(the above 
2. Zoom in on a cluster, either manually using the zoom tool or by clicking on 
the cluster directly.
3. Continue to zoom in until either the cluster or some or all of the markers 
in it are not correctly displayed.
A reliable example can be found in the above URL, by zooming in on Beijing 
(where there are 2 markers in the cluster).

Expected result:
The cluster should appear at all zoom levels until the appropriate zoom level 
threshold is reached, after which all individual markers are displayed.

Actual result:
At a certain zoom level, the cluster disappears and no individual markers are 
shown. Zooming back out may show the cluster, but this is not reliable.

Version: 1.0

Browser / Operating System:
Safari 5.1 / Mac OS X
Mobile Safari

Additional comments:
I have tried to pin down the cause of this issue, and found that this appears 
to be a CSS problem. No JavaScript code path differences are apparent between 
Firefox (which works) and Safari (which does not).
In the Cluster.prototype.addMarker() function, I tried removing the 
"this.markers_[i].setMap(null);" lines, which caused the clusters to remain on 
the map, though they are cut off as though by a bounding box (see attached 
screenshot; note that both clusters are cut off at the bottom, at different 
positions). This leads me to believe that the action of hiding the existing 
markers when creating the cluster icon is causing the cluster itself to be 
hidden by a misplaced bounding box.

Original issue reported on code.google.com by greenint...@gmail.com on 13 Nov 2011 at 9:59

Attachments:

GoogleCodeExporter commented 9 years ago
Note also that if you know where the cluster icon is supposed to show up, you 
can still click on it (even though it's invisible) and be taken to the 
zoomed-in view of the clustered markers. This means the browser is trying to 
render the cluster (as it should), but a CSS issue is preventing it from 
displaying.

Original comment by greenint...@gmail.com on 14 Nov 2011 at 3:12

GoogleCodeExporter commented 9 years ago
Have you tried using MarkerClustererPlus? Does it make a difference?

Original comment by garylitt...@gmail.com on 15 Nov 2011 at 9:11

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
MarkerClustererPlus has the same behavior.

I also have found that Safari 5.1.1 on Windows seems NOT to have this behavior. 
Chrome is also fine.

Original comment by greenint...@gmail.com on 16 Nov 2011 at 1:06

GoogleCodeExporter commented 9 years ago
Doesn't seem to be a problem with Safari 5.0.5 / Mac. All signs point to a 
Safari 5.1 bug.

Original comment by garylitt...@gmail.com on 16 Nov 2011 at 6:20

GoogleCodeExporter commented 9 years ago
I've submitted the relevant info (including a link to this issue) as a Safari 
bug. Meanwhile, is a workaround from this end likely? Since MobileSafari is 
affected, this is both high-exposure and unlikely to be addressed quickly from 
the browser end. I'm not sure what kind of policy covers situations like this 
(but naturally I'd like to be sure I can use this as the native supported API 
for clustering).

Original comment by greenint...@gmail.com on 16 Nov 2011 at 7:11

GoogleCodeExporter commented 9 years ago
Just noting that the issue does not seem to occur in the Webkit nightlies 
(11/22/2011).

Original comment by greenint...@gmail.com on 23 Nov 2011 at 4:25