IssueTracker

We have been made aware of several customer issues in the past few days with SSL/TLS due to this rollout having resumed.

At this stage, the best course of action is to ensure that your client TLS stack can dynamically work with intermediary certificates signed by any of the (~40) root CAs from https://pki.goog/roots.pem.

In other words, the root CA signing intermediary certificates for requests to https://maps.googleapis.com/* cannot be assumed to be static, nor can the set of root CAs be expected not to change before they expire.

We have published FAQs at the following addresses: https://pki.goog/faq/ is more high-level, and https://developers.google.com/maps/root-ca-faq is more technical.

Please note that many tools will only display and/or import the first certificate from https://pki.goog/roots.pem, which will not be sufficient to fix this situation.
Here are several sources that can be used to help you split the root.pem file into 1 file per certificate, if required by your tooling and software environment:

- https://developers.google.com/maps/root-ca-faq#how_do_i_extract_individual_certificates_from_rootspem
- https://geeklah.com/working_with_pem_files.html
- https://stackoverflow.com/questions/14660767/keytool-importing-multiple-certificates-in-single-file

As an immediate fix to get your Google Maps Platform requests working again, the main certificate to install is the "GTS Root R1" certificate, which begins at line 896 in the current roots.pem file. Please note that this issue may reoccur in the future if you don't install all the certificates.

@5

Have you tried using the 'idle' event?  This should replicate the events you named.

Berry, I starred this request; I also implemented an event handler that seems not to
have some of the issues you listed in your post:
http://notebook.kulchenko.com/maps/gridmove. The pixel arithmetic is still not
trivial, but it seems like you and I would still need to do our own calculations as
it's unlikely that the API will report pixel coordinates we both need to support
canvas tiles.

Paul (http://notebook.kulchenko.com/maps/)

Hi Paul,

Both you & I are doing way too much work for what was trivial with the old API.  I
will be happy with a browser independent way to obtain "mousemove" Lat/Lon
coordinates without adding an OverlayView.  Conversion back to pixels is easy.  I am
trying to avoid extracting information directly from the DOM which might change.

Berry

Berry, I agree; this would be sufficient and would simplify the code.

Paul.

Ben / Pamela,

What is the status ?  Anything on the horizon ?

Both Paul K & I have had to kludge something together.  The pixel arithmetic is
nasty.  Browser dependencies cannot be avoided.  An OverlayView is required just to
obtain the the tile offsets.  It is difficult to coexist with your other event handlers.

We're rewriting our app for V3 for our new version launch. We make constant use of
the mousemove event, and it is pretty much the main reason we cannot bring the system
fully into the V3 API.

Does anyone have any idea of the timeframe for this (and other) events to be
implemented into the API?

Also, I can't help wondering: Why were they taken off in the first place?

[Comment deleted]

No need to get the offset from the browser and do pixel conversions, just draw a
transparent polygon over your map and use the mousemove listener on the polygon. Each
time the idle event occurs on the map, redraw your polygon. The only limitation is
that you can't zoom out beyond level 3 unless you add some functionality for drawing
polygons that span 180+ degrees (which wouldn't be too difficult).

=================================================
Code:
=================================================
var map = new google.maps.Map();
var mapPolygonOverlay = null;

google.maps.event.addListener(map, 'idle', function()
{
  // Delete the previous mapPolygonOverlay if it exists
  if (mapPolygonOverlay != null)
  {
    var mapPolygonOverlayVertices = mapPolygonOverlay.getPath();
 
    // Remove all the points from the polygon
    for (var i = mapPolygonOverlayVertices.length; i >= 0; i--)
    {
      mapPolygonOverlayVertices.removeAt(i);
    }
  }      
 
  // Draw a polygon that is the map bounds
  var mapBounds = map.getBounds();
  var NE = mapBounds.getNorthEast();
  var SW = mapBounds.getSouthWest();
  var NW = new google.maps.LatLng(SW.lat(), NE.lng());
  var SE = new google.maps.LatLng(NE.lat(), SW.lng());
           
  var mapPolygonOverlayPaths = [NE, NW, SW, SE];
           
  mapPolygonOverlay = new google.maps.Polygon({
    paths: mapPolygonOverlayPaths,
    strokeColor: '#000000',
    strokeOpacity: 0.0,
    strokeWeight: 0,
    fillColor: '#000000',
    fillOpacity: 0.0
  });
           
  mapPolygonOverlay.setMap(map);
 
  // Add mousemove listener to polygon
  google.maps.event.addListener(mapPolygonOverlay, 'mousemove', function(event)
  {
    updateMouseLocation(event.latLng);
  });          
});

google.maps.event.addListener(map, 'zoom_changed', function()
{
  if(map.getZoom() < 3)
    map.setZoom(3);
});

For anyone interested, here is the code to allow for zooming out all the way. Just
add it right before you create your new google.maps.Polygon().

=================================================
Code:
=================================================
if(map.getZoom() == 2)
{
  var NC = new google.maps.LatLng(NW.lat(), map.getCenter().lng());
  var SC = new google.maps.LatLng(SW.lat(), map.getCenter().lng());
               
  mapPolygonOverlayPaths = [NW, NC, NE, SE, SC, SW];
}
else if(map.getZoom() == 1)
{
  NW = new google.maps.LatLng(NW.lat(), -180.0);
  NE = new google.maps.LatLng(NE.lat(), 180.0);
  SW = new google.maps.LatLng(SW.lat(), -180.0);
  SE = new google.maps.LatLng(SE.lat(), 180.0);
  var NC = new google.maps.LatLng(NW.lat(), 0.0);
  var SC = new google.maps.LatLng(SW.lat(), 0.0);
               
  mapPolygonOverlayPaths = [NE, NC, NW, SW, SC, SE];
}

A am looking for a REAL mousemove event handler returning Lat/Lon coordinates, not
some pathetic kludge.

Amen, brother!

Berry,

I'd like an official Map event handler from Google as well, but for now, mine is the
best solution. You might call it pathetic kludge, but at least it works in all
browsers--yours does not. I'd say mine is the only non-pathetic kludge on this page.

Easy now, gentlemen, easy now.  No need for kludge calling.

Sorry - tlc.  I realize mine is a kludge.  I called it such in comment #10.  I was
not aware it did not work in some browsers.

Please tell me in which browsers it fails:

    http://www.polyarc.us/polycluster/event.html

Thanks very much.

The mouse location does not work in Google Chrome or Safari. Yours is dependent on
the mouse's location from the left and top of the browser so when you stretch the
window horizontally, you will notice that the longitude values are further and
further away from what they are supposed to be. Or, if you scroll down the page
slightly, you will notice the latitude values are further and further away from what
they should be. This is due to the extra space between your mouse and the left/top of
the browser window.

Additionally, your map does not seem to pan correctly in any browser (IE7, Google
Chrome, Opera, Safari or Firefox) when using the mouse drag. I'm not sure if this is
due to some div you have placed over the map, but it is interfering with that in a
big way.

Hopefully, the next API v3 release update will include the map events we're looking
for.

I'm using a similar approach, although I calculate the position differently. I wonder
if my solution suffers from the same issues:

  http://notebook.kulchenko.com/maps/gridmove

Thanks very much TLC & Paul.

I know my mouse events are incompatable with Google's.  Double click & drag will both
fail.  Single click will center the map without changing the zoom level which is
deliberate.  It is easy enough to zoom.  Doing it automatically on every double click
is really annoying.

I was not aware of the Chrome / Safari issues.  I have neither installed.

Your approach is a good band-aid solution but Google ought not to dismiss the issue.
 I prefer not to load the poly support JS files if I do not have to.  I have my own
poly facilities which lack the bells & whistles of Google's polys but which improve
on performance (both size & speed).

If you have other polys, I believe you will have to be careful to establish the
zIndex order correctly to prevent chaos.

I trust Google is listening.  Three experienced developers are struggling to
implement a very trivial V2 feature in V3.  It ought to be a half day development
effort for Google.  It is very frustrating not to have such a basic capability available.

Paul,

Indeed it does suffer the same issues. I tore yours apart and re-built it myself to
see if your solution would work for me and the effects of stretching the browser and
scrolling down were very much prevalent.

Yours works if the map spans the entirety of the browser, but my application places a
much smaller map on a page full of other information and controls. Thus, my map is
not at the top left of the window, its location changes depending on browser width,
you can scroll up and down, moving the location of the map in relation to the top of
the window, and the content around the map grows/shrinks, modifying the map's
location; therefore, coordinates were quite a ways off from what they should have
been. I could have written an offset handler to grab the scroll value and measure
where the map div is at any given time, but it seemed like a lot of extra work and a
lot more possibilities where a slight change in the way a browser handles padding and
margins would destroy the whole system.

I've tested my solution in Google Chrome 3.0.195.33, IE 7-8, Firefox 3.5.5, and
Safari 4.0.4. It works exactly as it should in all of them. The only one it does not
work in is Opera 10.10 (though this is a problem with Google Maps itself -- e.g.
http://code.google.com/apis/maps/documentation/v3/examples/polygon-simple.html --
because Google Maps uses JavaScript code that is not W3C-compliant and Opera is all
about being W3C-compliant). I believe my solution _would_ work in Opera 10.10 if
Google Maps itself worked in Opera 10.10.

Thus, I submit my solution as the best answer to this problem until Google officially
releases the functionality. Hopefully it can help you guys until such a day comes.
Good luck!

Berry,

I agree Google should provide these map events. It is definitely frustrating
upgrading to v3 to find that something so trivial was lost.

I do actually draw additional polygons in my application (using them to define search
criteria for satellite imagery). The polygons all draw perfectly and all mouse events
occur exactly as they should without any hacking of z-index or the like. The only
thing I had to do was add a mousemove event listener to any additional polygons the
user draws on top to make sure that while their mouse is over said polygons, the
mouse location is still being updated. This was simple, however. It was 1 line of
code--literally just adding a listener.

Hi Paul,

I believe both you & I are failing to make adjustments for the map being resized.  If
you & I replace our "idle" event listeners with "bounds_changed" event listeners, it
ought to help.

I have another little suggestion.  If you add the diameter of your dot in pixels to
the "style.width" & "style.height" of each CANVAS element & subtract the radius of
your dot in pixels from the "style.top" & "style.left" of each CANVAS element, the
dot will not be clipped at the edge of the CANVAS element.  Your tiles will overlap
but will be transparent except for the dots.  Each dot will be contained in exactly
one tile rather than split across adjacent tiles.

Also, you can add your own properties to your DIV elements containing your CANVAS
elements.  If you do, you will not have to extract browser dependent offsets from
Google's DIV elements.  If you have just one dot, it might make sense to abandon the
use of tiles.  Instead, the dot can reside in its own CANVAS element which you can
reposition.

For what it is worth, a map "mousemove" event listener must be REALLY FAST.  I am
reluctant to build anything relying on a poly "mousemove" event listener which
requires several tiled CANVAS or SVG or VML elements plus a large JS support file.

Hi TLC

I've got a thing with your sample up and working pretty well. Now my problem is that events on the
mapPolygonOverlay, are not registrered when i am at/over a marker. I need to track lat/lng of the mouse
position, even when i move the mouse over a marker.
I guess mapPolygonOverlay is at a lower z-index than the marker, but i can't find a way to change this.

Do you have any ideas for a work around or am i missing something?

Thanks.

You could add a 'mouseover' event listener to the marker itself and return the
LatLng of the marker when it fires. If that does not suffice, the Marker class does
have a method setZIndex(zIndex:number) that you may want to look at. I'm not
entirely sure it will allow you to place your marker behind the polygon, though.

yeah, i did look into that, but it only fires once, so it doesn't continously update the lat-lng position. I've also
tried playing around with the setZIndex of the marker, but with no luck, which makes sence when i look at the
map pane documentation here:
http://code.google.com/apis/maps/documentation/v3/reference.html#MapPanes

What is interesting is how mousemove would work if they added it for the map canvas as this issue suggests.

I haven't played around with v2, but does anyone know if the mousemove event on the map canvas there
returns anything when a marker is hovered?

I do. The mousemove event on the canvas does return the LatLng even when over a
marker (though I've only tested it with non-clickable markers). You may want to look
in to using v2 for now until Google can implement this in v3. But you should ask
yourself, is the tiny area underneath the marker that important to update the LatLng on?

Please put this feature back. It would save a lot of headache.

We've held off implementing this so far because we were concerned that projecting pixel
coordinates to LatLng (and creating LatLng objects) on mouseover would bog down slow
browsers.  But clearly this is highly desired so we're looking into it now.

Ben

Sorry, I meant mousemove not mouseover.  I've seen a browser fire mousemove *multiple
times per pixel* that the mouse moves over, and that same browser bogged down when I
created 1 object per mousemove.  We may compromise by throttling the mousemove events.

If the coordinates have not changed since previous "mousemove", do nothing.  If the
user has not registered an event listener for "mousemove", do nothing.

I am rather disappointed that the "mousemove" event returning a LatLng in not
available. Its was in v2 ;-))))))))))))))))))))))))))))

I want to upgrade.

Please do not throttle the "mousemove" event handler unless you also provide an
option to disable the throttle.  The purpose of the "mousemove" event handler is to
provide quick feedback for changing the cursor, for tool tips, for other uses
requiring instantaneous feedback.  If each mouse movement must be approved by some
black box timing mechanism, it is essentially worthless.  If you must constrain it, I
will implement my own.  Abandoned function closures cause memory leakage.  A well
constructed event handler can run all day without memory leakage.

Clearly V2 is able to implement a "mousemove" event handler without throttling.  If
V3 must impose an arbitrary throttle, I will not use it.  Wasteful function closures
are the issue, not the number of times the function is called.  By the way, functions
closures are a horrible way to implement any event listener.

If others agree throttling is a mistake, please let your opinions be known.
Otherwise, you will be stuck with an unresponsive "mousemove" event handler which
will be essentially worthless.

How was it fixed? How to get notiifed when these events are thrown?