Fixed
Status Update
No update yet.
Comments
xa...@google.com
yb...@google.com
FYI, I took the clustering example from the Google Maps API Guides page at...
https://developers.google.com/maps/documentation/javascript/marker-clustering
... and I changed the Google Maps version to v=3.exp
... and hosted the result athttp://www.GaryLittle.ca/mc-bug.html
Load this address in your iOS browser (Safari) and try clicking any of the clusters. Nothing happens.
This code uses the old MarkerClusterer but I'm sure the behaviour will be identical if using MarkerClustererPlus.
... and I changed the Google Maps version to v=3.exp
... and hosted the result at
Load this address in your iOS browser (Safari) and try clicking any of the clusters. Nothing happens.
This code uses the old MarkerClusterer but I'm sure the behaviour will be identical if using MarkerClustererPlus.
xa...@google.com
I've just verified that this problem also affects Android devices (running Chrome).
lo...@gradle.com
yb...@google.com
+1 on this bug, likewise it only appears to be an issue when gesture is set to ‘greedy’
lo...@gradle.com
Thanks for all the bug reports. I am sorry.
We are trying to work out the best solution.
An explanation:
In greedy mode, we need to prevent the page from scrolling, and to do this the maps API calls preventDefault() on the touchstart event. Unfortunately, this also prevents the browser from firing a click event.
A workaround / solution:
Listen for touchstart, and call stopPropagation(). This means the maps API will not have a chance to call preventDefault() and your click will be preserved. It also has the effect that clicks on the clusters won't fall through to the map, which is probably what you wanted.
div.addEventListener('touchstart', function(e) {
e.stopPropagation();
});
div.addEventListener('click', function(e) {
// should work as before.
});
We are trying to work out the best solution.
An explanation:
In greedy mode, we need to prevent the page from scrolling, and to do this the maps API calls preventDefault() on the touchstart event. Unfortunately, this also prevents the browser from firing a click event.
A workaround / solution:
Listen for touchstart, and call stopPropagation(). This means the maps API will not have a chance to call preventDefault() and your click will be preserved. It also has the effect that clicks on the clusters won't fall through to the map, which is probably what you wanted.
div.addEventListener('touchstart', function(e) {
e.stopPropagation();
});
div.addEventListener('click', function(e) {
// should work as before.
});
yb...@google.com
Great, that workaround seems to solve the problem.
But greedy mode did work with MC before 3.32exp so what changed in 3.32exp to break it?
I'll update MarkerClustererPlus at GitHub once I've tried this fix out on a few other maps I have created.
But greedy mode did work with MC before 3.32exp so what changed in 3.32exp to break it?
I'll update MarkerClustererPlus at GitHub once I've tried this fix out on a few other maps I have created.
je...@google.com
lo...@gradle.com
Good afternoon! I updated the latest version of MarkerClustererPlus, but my problem is not solved! When clicks on the cluster, the click event occurs first on the map and I have a marker, then the cluster event is triggered and a zoom occurs
yb...@google.com
#11 Yes, I see what you mean. The #9 workaround results in a click event on the map when you click a cluster marker. This didn't happen before.
More ideas from Google on this subject would be welcome from Google!
More ideas from Google on this subject would be welcome from Google!
lo...@gradle.com
More on my #12 comment...
Actually, it's not the #9 workaround that's causing the problem. It's just another side effect of using v3.32 exp instead of earlier stable releases.
In other words, with 3.32 exp only, an attempt to click a cluster marker results first in a click event on the map followed by a click event on the cluster marker. This doesn't happen when you click a regular marker.
Note: there is specific code in the click handler for the marker cluster DIV to stop event propagation, but it's of no use in 3.32 exp because the click reaches the map first.
Hint to Google: is this perhaps something to do with the fact that the cluster marker is in the overlayMouseTarget pane?
Actually, it's not the #9 workaround that's causing the problem. It's just another side effect of using v3.32 exp instead of earlier stable releases.
In other words, with 3.32 exp only, an attempt to click a cluster marker results first in a click event on the map followed by a click event on the cluster marker. This doesn't happen when you click a regular marker.
Note: there is specific code in the click handler for the marker cluster DIV to stop event propagation, but it's of no use in 3.32 exp because the click reaches the map first.
Hint to Google: is this perhaps something to do with the fact that the cluster marker is in the overlayMouseTarget pane?
mz...@gmail.com
This is a very complex issue, and it's hurting my head a bit.
First, let's try and come up with a workaround that works:
1. If you stopPropagation the touchstart, then the browser generates a mousedown, mouseup, click as usual.
2. The Maps API listens to the mousedown and mouseup, and interprets this as a click.
- So you should stopPropagation the mousedown as well. And pointerdown just to be safe.
- This is actually a bug, and we have a fix in the pipeline. We intend to listen to click events instead of mousedown and mouseup. Then you can stopPropagation the click.
Second, there are actually a few different things you might want.
A. listen for clicks on the overlay
B. stop clicks on the overlay from bubbling up to the map.
C. enable/stop map panning/zooming on the overlay
So, initially we were discussing A, but then it turned out that we also needed B.
What about C... Do you want C?
First, let's try and come up with a workaround that works:
1. If you stopPropagation the touchstart, then the browser generates a mousedown, mouseup, click as usual.
2. The Maps API listens to the mousedown and mouseup, and interprets this as a click.
- So you should stopPropagation the mousedown as well. And pointerdown just to be safe.
- This is actually a bug, and we have a fix in the pipeline. We intend to listen to click events instead of mousedown and mouseup. Then you can stopPropagation the click.
Second, there are actually a few different things you might want.
A. listen for clicks on the overlay
B. stop clicks on the overlay from bubbling up to the map.
C. enable/stop map panning/zooming on the overlay
So, initially we were discussing A, but then it turned out that we also needed B.
What about C... Do you want C?
lo...@gradle.com
OK, I've taken your suggestion and I call stopPropagation() on mousedown (and pointerdown). I was already calling stopPropagation() after a click. This change prevents the click from reaching the map, so that's the good news.
Now the problem is that I can't initiate a panning action that begins on a cluster marker (as you could before). I guess that's C... so, yes, I want C as well.
Now the problem is that I can't initiate a panning action that begins on a cluster marker (as you could before). I guess that's C... so, yes, I want C as well.
yb...@google.com
Oops, the touchstart stopPropagation workaround for v3.32exp prevents clicks from from being handled properly on the stable release of GM. Aargh. Any suggestions for how to detect the experimental version?
yb...@google.com
You can inspect google.maps.version, although you'll have to do a little string parsing.
yb...@google.com
I think v3.32 has two bugs.
1. v3.32 doesn't synthesize a "click" event for tap on a greedy map. This makes it hard to listen for *tap* on OverlayViews on a greedy map.
2. v3.32 doesn't respect mouse "click" stopPropagation(). This will be fixed shortly.
(a) Note, however, that we never respected tap "click" stopPropagation(). Taps always led to map click events.
So "click" events on the map are not a big deal for markerclustererplus, right?
The workarounds for 1 are:
- use cooperative instead of greedy
- stopPropagation on "touchstart" but then you can't pan the map by dragging a cluster
- detect tap by listening to "touchstart", "touchmove" and "touchend".
I'll keep this bug updated with our progress. We're working on it.
1. v3.32 doesn't synthesize a "click" event for tap on a greedy map. This makes it hard to listen for *tap* on OverlayViews on a greedy map.
2. v3.32 doesn't respect mouse "click" stopPropagation(). This will be fixed shortly.
(a) Note, however, that we never respected tap "click" stopPropagation(). Taps always led to map click events.
So "click" events on the map are not a big deal for markerclustererplus, right?
The workarounds for 1 are:
- use cooperative instead of greedy
- stopPropagation on "touchstart" but then you can't pan the map by dragging a cluster
- detect tap by listening to "touchstart", "touchmove" and "touchend".
I'll keep this bug updated with our progress. We're working on it.
hu...@google.com
MarkerClustererPlus normally handles clicks on its own and does not want to pass them on to the map. So it does want to stop a tap "click" on iOS / Android from being reported to the map. (In fact, there is a bug filed on Github on that very subject.) At present there is already a stopPropagation call in the click handler that (I guess) works only on a desktop OS.
I can't use cooperative instead of greedy because that means 2-finger panning and that's not what users expect especially on a full-screen map such as the ones I typically create.
stopPropagation on touchstart fails on the current stable release of GM. I guess I could check google.maps.version but that's an ugly solution. Might be the easiest though.
Detecting a tap by tracking touchstart/touchmove/touchend -- not sure what's involved here but I suppose if I could detect a gesture that looked like a tap I could call the click handler after touchend. This is going to challenge my skill set! Would GM simply generate a map "click" anyway?
I'm leaning to version checking......
Now my head is hurting.
I can't use cooperative instead of greedy because that means 2-finger panning and that's not what users expect especially on a full-screen map such as the ones I typically create.
stopPropagation on touchstart fails on the current stable release of GM. I guess I could check google.maps.version but that's an ugly solution. Might be the easiest though.
Detecting a tap by tracking touchstart/touchmove/touchend -- not sure what's involved here but I suppose if I could detect a gesture that looked like a tap I could call the click handler after touchend. This is going to challenge my skill set! Would GM simply generate a map "click" anyway?
I'm leaning to version checking......
Now my head is hurting.
ja...@google.com
OK, I've now added the version checking so I now have functionality restored on older stable releases of GM.
I'm still stuck, on GM v3.32 exp, with tap clicks on clusters being passed through to the map and no map panning when the pan starts on a cluster.
I'm still stuck, on GM v3.32 exp, with tap clicks on clusters being passed through to the map and no map panning when the pan starts on a cluster.
ja...@google.com
At about 8 pm PST last night (March 5) -- 3 pm March 6 in Sydney -- a new version of the experimental API seems to have gone live.
This API breaks the marker clusterer badly. In particular, the clusterer code I call in response to a map idle event (which adjusts which markers are being managed and involves accessing a database and repaint()-ing the clusterer) seems to generate another idle event. The result is an infinite loop where the DB is repeatedly searched in response to idle events that never end.
I didn't touch anything at my end!
All works perfectly with Google Maps API v3 stable and has done so for many years.
What happened?
This API breaks the marker clusterer badly. In particular, the clusterer code I call in response to a map idle event (which adjusts which markers are being managed and involves accessing a database and repaint()-ing the clusterer) seems to generate another idle event. The result is an infinite loop where the DB is repeatedly searched in response to idle events that never end.
I didn't touch anything at my end!
All works perfectly with Google Maps API v3 stable and has done so for many years.
What happened?
hu...@google.com
I've just checked and the very same problem now also occurs when using the old MarkerClusterer. (I'm using MarkerClustererPlus, of course.)
ja...@google.com
hu...@google.com
This new issue is tracked under https://issuetracker.google.com/74214837
We are working on a fix for that.
We are working on a fix for that.
lo...@gradle.com
I believe our most recent release fixes the issue. Let me know if there are still problems.
ta...@gmail.com
Works for me - many thanks!
hu...@google.com
We've got it working now. Great.
We're using MarkerClusterer by the way.
We're using MarkerClusterer by the way.
[Deleted User] <[Deleted User]>
all good, thanks a lot!
vi...@gmail.com
I have verified that a tap on a cluster marker no longer results in a click event on the map. I can now also begin a pan from a cluster marker. So both those issues have been fixed. I've had to keep the version checking in #20 to stop propagation after touchstart on 3.32+ but that's ok.
Description
- AndroidJavaCompile.dataBindingDependencyArtifacts is missing a `@PathSensitive` annotation, so it's treated as `ABSOLUTE` (this is tracked in
- A number of absolute paths are specified as annotation processor parameters in `options.compilerArgs`:
- -Aandroid.databinding.minApi=26
- -Aandroid.databinding.enableDebugLogs=0
- -Aandroid.databinding.sdkDir=/Users/lptr/Library/Android/sdk
- -Aandroid.databinding.bindingBuildFolder=/private/var/folders/kw/65bvkdfn6cv_4g4vszf1wm_80000gn/T/junit4630811611102055048/junit5868716240725709754/library/build/intermediates/data-binding-compiler/debug
- -Aandroid.databinding.enableForTests=0
- -Aandroid.databinding.modulePackage=org.gradle.android.example.library
- -Aandroid.databinding.generationalFileOutDir=/private/var/folders/kw/65bvkdfn6cv_4g4vszf1wm_80000gn/T/junit4630811611102055048/junit5868716240725709754/library/build/intermediates/bundles/debug/data-binding
- -Aandroid.databinding.xmlOutDir=/private/var/folders/kw/65bvkdfn6cv_4g4vszf1wm_80000gn/T/junit4630811611102055048/junit5868716240725709754/library/build/intermediates/data-binding-info/debug
- -Aandroid.databinding.artifactType=LIBRARY
- -Aandroid.databinding.printEncodedErrors=0
- -Aandroid.databinding.isTestVariant=0
- -Aandroid.databinding.exportClassListTo=/private/var/folders/kw/65bvkdfn6cv_4g4vszf1wm_80000gn/T/junit4630811611102055048/junit5868716240725709754/library/build/intermediates/data-binding-info/debug/_generated.txt
- A source file is generated called `DataBindingInfo.java` with a random UUID that changes every time a new file is generated:
package android.databinding.layouts;
import android.databinding.BindingBuildInfo;
@BindingBuildInfo(buildId="9dfdb009-9c54-4b16-8df1-956cd6e00303")
public class DataBindingInfo {}