| Issue 1077: | Bug: enable/disableEditing within polyline mouseover/mouseout events breaks css pointer boundaries | |
| 3 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
What steps will reproduce the problem? Please provide a link to a demonstration page if at all possible, or attach code. Test page, with regression capability at http://ws.mapmyfitness.com/~jeff/gtest/testpointer/?v=2.145 Video demo at http://screencast.com/t/t3VEp83Bb The page can render a passing case, and a failing case. In the passing case, the pointer boundaries are correct. In the failing case, the mouse pointer boundaries render incorrect, after enable/disableEditing are called withing polyline mouseover/mouseout events. 1. Move mouse over map, note crosshair pointer (correct) 2. Move mouse over and out of polyline 3. Note that pointer is not a hand, and not a crosshair (incorrect) Note that this appears to be a timing issue, and steps 2-3 may need to be repeated to reproduce. What version of the API are you using? (In the JS API, you can tell this by checking the value of G_API_VERSION.) What operating system and browser are you using? ********************************************************* For developers viewing this issue: please click the 'star' icon to be notified of future changes, and to let us know how many of you are interested in seeing it resolved. ********************************************************* |
||||||||||||||
,
Feb 27, 2009
Fantastic, thanks for your effort in putting together the test page and video. I've reported the bug to the team.
Status: Accepted
Labels: Class-GPolyline Internal-1680906 |
|||||||||||||||
,
Mar 29, 2009
Issue 1183 has been merged into this issue. |
|||||||||||||||
,
May 24, 2009
Changing status of "Accepted" issues to "Acknowledged", to clarify their state. We may not be able to resolve all bugs or fulfill all feature requests, but we do thank you for filing them, and we will continually revisit all acknowledged issues and evaluate their feasibility. Thanks!
Status: Acknowledged
|
|||||||||||||||
,
May 30, 2009
There was some confusion with the change from the "Accepted" status to the "Acknowledged" status, and some developers took that to mean that their bug was being downgraded. This was only a wording change, not a priority change. We are still working on fixing many bugs (particularly the regression bugs), so a fix for your bug may still be coming in the future. After a discussion in the forum, we will now use "Confirmed" instead of "Acknowledged". This status indicates that we have verified the bug, reported it internally, and it is included in the list of bugs that we review each week (when determining what to fix next).
Status: Confirmed
|
|||||||||||||||
,
Aug 18, 2009
(No comment was entered for this change.)
Status: FixedNotReleased
|
|||||||||||||||
,
Aug 27, 2009
(No comment was entered for this change.)
Status: Fixed
Labels: Fixed-2.173 |
|||||||||||||||
,
Sep 11, 2009
Unfortunately, I still see this issue in v 2.173. The test case above does not always show the issue, but it can be reproduced fairly easily at http://www.mapmyrun.com/create_new . If you draw a few points, the problem is exposed. |
|||||||||||||||
,
Sep 11, 2009
Thanks for the followup Jeff. I believe I reproduced the same problem against the latest version 2.173. I'll ping the team to investigate again.
Status: Confirmed
|
|||||||||||||||
,
Sep 22, 2009
Hey Jeff, Is there anyway you can replicate the problem in http://www.mapmyrun.com/create_new in a smaller more isolated example, like you did in http://ws.mapmyfitness.com/~jeff/gtest/testpointer/?v=2.145? The 'create_new' page has many moving parts and would make it really difficult to track down the root cause. Thanks!
Status: NeedsMoreInfo
|
|||||||||||||||
 Sign in to add a comment
|
|||||||||||||||
