Status Update
Comments
zi...@google.com <zi...@google.com> #2
This is to confirm that we plan to resume the rollout of the new cross-signed root CA certificate as described in
The rollout will be very gradual, with incremental launches across the Google Maps Platform services and regions, and its phases will proceed depending on engineering evaluations rather than by a defined timetable. The change will be transparent to the vast majority of Google Maps Platform API clients, including all mainstream maintained OS versions.
For more information, please see the FAQ resources listed in
zi...@google.com <zi...@google.com> #3
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
In other words, the root CA signing intermediary certificates for requests to
We have published FAQs at the following addresses:
nd...@gmail.com <nd...@gmail.com> #4
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:
-
-
-
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.
ad...@gmail.com <ad...@gmail.com> #5
To help customers using Java or Mozilla NSS, we have updated the Java keytool
and NSS certutil
sections in our
am...@gmail.com <am...@gmail.com> #6
Dear developers, the new GTS Root R1 Cross certificates have now fully rolled out to all Google Maps Platform services.
nd...@gmail.com <nd...@gmail.com> #7
*(Note: replicated with Safari 9.1. I no longer have access to Safari 8 because autoupdate.)
- Browser: Safari 9.1 (11601.5.17.1)
- Gmaps API v3.exp
Steps to reproduce and behavior are identical to the Safari 8 test case, except:
1. Changing the Safari 9 user agent does not resolve.
2. The CSS injection fix works, provided "Version/8." is changed to "Version/9."
Again, the same behavior is observed when "Show Compositing Borders" is enabled in Safari -- unless you see a yellow border around every map tile, in the words of the South Park ski instructor, you're not gonna have a good time.
For whatever reason, in the time since this bug was initially filed, Chrome can now handle map tiles without transform CSS hacks. Perhaps the layer squashing now logic identifies map tiles or something. Unfortunately, Safari still needs the CSS.
For anyone who just wants to fix it quickly, here's a glorious CSS hack that targets OS X Safari 7.1+ only, which I can confirm works in Safari 9.1:
_:-webkit-full-screen, _::-webkit-full-page-media, _:future, :root #map_canvas div {
-webkit-transform:translateZ(0px);
-webkit-backface-visibility:hidden;
}
(where "map_canvas" is whatever div you pointed GMaps at that has the tiles)
I would personally recommend using the above CSS hack until if and when this bug is fixed.
zw...@google.com <zw...@google.com> #8
I've tried this on iOS safari and on a MacbookPro with Safari 11601.7.7 loading this page:
And then going fullscreen.
The reason Chrome can do it, is because we have a applied a 'will-change: transform' Css property. Safari probably doesn't support this, but removing the translateZ didn't regress on any Safari we've tested this on.
If we can reproduce it, we can readd it the translateZ for Safari, but without that I would be hesitant to add browser specific code without seeing the effect.
Description
========
Google Maps API v3 is not optimally supporting Safari 8 for OS X, and suffers significantly degraded performance.
This is a regression from Safari 7, is related to user-agent string match behavior, is 100% replicable and likely relatively trivial to triage/fix.
Expected behavior:
==================
Safari 8 OS X's performance with Gmaps API v3 is on par with Safari 7.
Actual behavior:
================
Safari 8 OS X's performance is very poor, with frequent UI freezing / janking and low FPS.
Steps to reproduce:
===================
1. Open the sample test case .html in Safari 8 OS X
2. To make it easier to replicate, hit the button to add two raster layers. Or not.
3. Pan the map around, preferably with the arrow keys as they reproduce better than random mouse dragging. Note the terrible performance.
4. Click "Inject... Fix". Note the framerate immediately recovers and all freezing/janking is gone.
Never Lupus, Occasionally User Agent:
5. In Safari, click Develop -> User Agent -> Safari 7. (enable Developer Mode in Prefs if you don't see the Develop menu) Reload/retest.
6. Note with Safari 7 user agent, the performance is fine.
7. Click Develop -> User Agent -> Custom. Apply this, which is Chrome 41's useragent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36" [NB: DO NOT use Safari's built-in Chrome useragent, it is outdated]
8. Now reload/retest. Note with Chrome 41's useragent, Safari 8's performance is as expected.
Safari 7 Confirms Half-Life 3:
9. Now start Safari 7 OS X and retest. Performance is as expected.
10. Now, in Safari 7, click Develop -> User Agent -> Safari 8. Reload, retest.
11. Note Safari 7 with Safari 8's UA has extremely poor performance.
But Surely Chrome Can Survive Anor Londo:
12. Now fire up Chrome, and download an extension to use faux useragents.
13. Set Chrome's useragent to Firefox or Safari 8 OS X.
14. Note Chrome's performance with Firefox or Safari 8 UAs is also poor. Not as bad as Safari's, but hardly pleasant to use.
Summary:
Browser User Agent Result
--------------- ---------------- ------
Safari 8 OS X Default **FAIL** [current production behavior]
Safari 8 OS X Default OK [with injected CSS fix]
Safari 8 OS X Safari 7 OS X OK
Safari 8 OS X Safari 8 Mobile OK
Safari 8 OS X Chrome 41 OK
Chrome 40 OS X Default OK [current production behavior]
Chrome 40 OS X Firefox Fail
Chrome 41 OS X Default OK [current production behavior]
Chrome 41 OS X Firefox Fail
Safari 7 OS X Default OK [current production behavior]
Safari 7 OS X Safari 8 OS X Fail
(assuming the ASCII table whitespace doesn't get butchered)
Additional Notes:
=================
Spoiler warning!
Both Chrome and Safari do something called "layer squashing", which does not do tiled web map performance any favors.
To prevent this behavior, setting certain 3D transform type styles is necessary (-webkit-transform:translateZ(0px)). Google Maps API v3 does this for Chrome, Safari 7, and Safari 8 Mobile, yet not Safari 8 OS X.
The reason this fails is the translateZ hack/fix isn't being performed for Safari 8's useragent string. Simple as that. Either it never got updated, or there's a typo in some regex expression or something.
Perhaps ideally both Safari and Chrome should not require this, but any long-term solution seems... long-term. Thus a useful triage for every Safari 8 OS X / Gmaps API v3 user would be to make the useragent match work.
Performance Notes:
==================
Not all forced translateZ(0px)s are created equal. A significant performance difference was found in testing for Safari 8, where setting this on the tile div containers was far more performant than on the tile image elements.
(try it: inject the fix in the test case, then edit the style live and change div to img)
As part of a fix, I would suggest testing that not only for Safari 8 OS X, but also for browsers currently getting a Gmaps API-supplied translateZ(0px) such as Safari Mobile and Chrome. If the preliminary results from my testing hold up there as well, this could potentially represent a performance improvement for all WebKit/Blink-derived browsers. Which would be nice.
However, note that my fix in the test case is somewhat differently mechanically (CSS style selector) than what the Gmaps API is doing, and this requires further research in any case.
Also, speaking of performance, you guys have a memory leak, directly related to translateZ(0px). See below.
Related Bugs:
=============
1. WebKit
2. GMaps API
[1]
[2]
Testing Methodology:
====================
Two different MacBook Pros, running both OS X 10.10 and 10.9. Chrome 40, 41 for OS X. Safari 7, 8 for OS X. See WebKit
Attachments:
============
[safari8-gmaps.html] - this is your test case
[chrome40.png] - layer compositing borders on Chrome 40. Note they are aligned with map tiles.
[safari8.png] - layer compositing borders on Safari 8 by default, *while* panning the map. They only briefly appear, then get squashed.
[safari8fix.png] - layer compositing borders on Safari 8 with the hack fix in the test case. Also what Safari 7 looks like.
As you can see from the images, if you don't have yellow boxes around the tiles, to quote the South Park ski instructor, you're not gonna have a good time.