Closed Bug 540491 Opened 15 years ago Closed 13 years ago

creating placemarks while editing custom google maps broken

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: tnikkel, Unassigned)

References

(
URL
)

Details

While following dbaron's steps to reproduce in bug 540450 I came across this bug.

Goto Google Maps, make sure you are logged in. Goto My Maps, Create a Map. Then try to create a placemark by clicking on the blue peg button in the top left of the map. The blue peg doesn't follow your mouse and just stays in one spot.
It looks like the problem is that google maps is setting a capture and expecting it to still capture after mouseup.
Yep, I've seen this too.  Sorry for not filing; there were half a dozen things wrong with Google Maps editing...
(In reply to comment #1)
> It looks like the problem is that google maps is setting a capture and
> expecting it to still capture after mouseup.

We always stop capture on mouseup to prevent abuse, whereas IE doesn't which means that if releaseCapture isn't explicitly called, any mouse events don't target anything else, even mouse events on the browser UI itself get retargeted. We don't want that to happen.
So then this should be an evangelism bug to get Google Maps to support our differences in setCapture?
Who needs to be cc'd so this gets some attention?
Assignee: nobody → english-us
Component: Event Handling → English US
Product: Core → Tech Evangelism
QA Contact: events → english-us
Version: Trunk → unspecified
Some progress on tracking a regression was made in the dupe.  Matt tracked it to this range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf0fdec8f43b&tochange=912c6ae3b70c

Supernova's guess was bug 503943.
Excuse my for not reading well enough, I can see this being a Google error and the product not working but why did it work before in Trunk and still work now in 3.6?  And if "capture on mouseup to prevent abuse" is a security problem then should someone file a bug on 3.6 to stop this behavior?
Before bug 503943 landed Firefox didn't support calling setCapture on an element. Bug 503943 landed on trunk after 3.6 branched, so it isn't in 3.6. Google Maps guards its calls to setCapture by doing "element.setCapture && element.setCapture()" so it only calls it if the browser supports it. Unfortunately there are differences in how Firefox implements setCapture to how IE does, and the one mentioned in comment 3 is causing this bug.
(In reply to comment #9)
> Unfortunately there are differences in how Firefox implements setCapture to how
> IE does, and the one mentioned in comment 3 is causing this bug.

To be specific, Firefox doesn't support the aspect of setCapture that can be abused to prevent ui interaction.
(In reply to comment #4)
> So then this should be an evangelism bug to get Google Maps to support our
> differences in setCapture?

How to progress on that ? Maybe Google has a plan for an update already, that one is really painful and easy to hit.
I reported this problem on the Google Map but moving that placemark worked... but moving an edited "my map" placemark still doesn't,  Maybe they've updated their code for some placemarks and not others?
This problem exists (for sure, maybe earlier beta versions are also suffering) in Fx4b11-rc1, but in Fx3.6 everything is ok.
(In reply to comment #15)
> This problem exists (for sure, maybe earlier beta versions are also suffering)
> in Fx4b11-rc1, but in Fx3.6 everything is ok.

Comment 3 and comment 9 explain the problem.  It's not a Firefox bug but an issue with Google.  This bug is still open because either Google hasn't responded to Mozilla evangelism on the issue or Mozilla hasn't yet done any evangelism.  I submitted a comment to Google about a year ago linking to this bug and you can too.  It might eventually get to a Google dev.
Fx4 was launched with this bug (no matter whose fault it is). Is there anything you can do to workaround this bug?

The users only know it works with 3.6 and Chorme and it is broken with Fx4. Many communities use google maps to show users and track activities.

I am sure google has really a need to get My Maps working in Fx4 or maybe they should just add a „download Chrome now“ box ^^
Backward compatibility is important. Google maps users WILL leave Fx4 behind
and select a working browser, no matter whose bug it is.
I think the relevant question to ROC, Timothy, Neil, David and any of the others (I think) work for Mozilla is have any of you done evangelism with relevant employees at Google?

Is there any evangelism we bugzilla users should engage in?  I've created http://www.google.com/support/forum/p/maps/thread?tid=15e6ce3bbdf0ef7f&hl=en but predict 0 people with the ability to fix the problem will view that.

If we do get in contact with someone at Google who needs better explanation of the problem whose contact information should we give them at Mozilla?

Thanks, and hopefully this is more constructive than bugspam.
(In reply to comment #20)
> I think the relevant question to ROC, Timothy, Neil, David and any of the
> others (I think) work for Mozilla is have any of you done evangelism with
> relevant employees at Google?

Yes, we're in contact with the right people.
Hi Fritz: regarding to your prediction "0 people with the ability to fix the problem will view that" I have (using my TC-Status) escaleted the according thread directly to Google in Mountain View. Hope they will pass it along to the right folks.
Best
ehg 
(In reply to comment #20)
> I think the relevant question to ROC, Timothy, Neil, David and any of the
> others (I think) work for Mozilla is have any of you done evangelism with
> relevant employees at Google?
> 
> Is there any evangelism we bugzilla users should engage in?  I've created
> http://www.google.com/support/forum/p/maps/thread?tid=15e6ce3bbdf0ef7f&hl=en
> but predict 0 people with the ability to fix the problem will view that.
> 
> If we do get in contact with someone at Google who needs better explanation of
> the problem whose contact information should we give them at Mozilla?
> 
> Thanks, and hopefully this is more constructive than bugspam.
Hi, this was indeed escalated recently and has come to the attention of the Maps team.  I can get this fixed in Maps, but it's still not entirely clear to me what the solution is. I am not specifically familiar with the SetCapture code in question.  It sounds like you are asking us to make an additional SetCapture call after mouseup?
Firefox only allows setCapture to work when a mouse button is down. So the code in question would need to be changed to deal with this difference. Here is a blog post outlining this and other differences in how setCapture works in Firefox: http://enndeakin.wordpress.com/2009/08/27/mouse-capturing/
I see.  So the simplest course might actually be to guard our existing use of setCapture here so that it is only used on IE, as indeed it was prior to FF4.
Indeed that solves the problem (actually instead of checking for IE, I check for non-FF).  I'll have to make sure it doesn't break anything else.  If not it should be live by the end of next week.
By the way, there is a related problem with dragging the features to reorder them in a My Map.  It doesn't work on FF4 for the same cause.  Should be fixed at the same time.
That sounds like bug 540450.
(In reply to comment #26)
> (actually instead of checking for IE, I check
> for non-FF)

Please make sure that your check for "not Firefox" is actually a check for "not Gecko, or Gecko version < 2" instead, so that we don't run into issues like bug 334967. Or sniffing specifically for IE should be fine, too.
Chris: Thanks for the comment, I'll make sure before submittal.

Timothy: Yes, bug 540450 describes the other problem fixed by this.
Blocks: 540450
I've verified that the fix is live in Maps as of late yesterday.

Thank you all for providing enough information to make the fix relatively easy and painless, especially Timothy Nikkel for distilling the issue so well: "Firefox only allows setCapture to work when a mouse button is down."

I'm sure there were good reasons for doing so, but reimplementing another browser's feature with incompatible improvements will inevitably lead to bugs like this. And the simplest fix for now is to treat Gecko setCapture as if doesn't exist.
Thanks for fixing it!
I can verify that this works for me now for what that's worth.  Thanks Google for fixing this. :)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.