Fixed
Status Update
No update yet.
Comments
zi...@google.com
Just discovered that when you drag the marker off the map and it vanishes you can drag
the map in the direction that the marker vanished and the marker will appear somewhere
else on the map (presumably to a place you dragged it to where it became stuck)
the map in the direction that the marker vanished and the marker will appear somewhere
else on the map (presumably to a place you dragged it to where it became stuck)
nd...@gmail.com
This is the intended behaviour. If you want the map to follow/pan to a marker when you
drag it, you can add events to handle that.
drag it, you can add events to handle that.
ad...@gmail.com
Sorry, I misread you bug.
am...@gmail.com
how can stop dragging(marker or map) when out of the map
(ie.: map.getBounds().getSouthWest().lat()<-85 ||map.getBounds().getNorthEast().lat()>85 )
(ie.: map.getBounds().getSouthWest().lat()<-85 ||map.getBounds().getNorthEast().lat()>85 )
nd...@gmail.com
OP here, there's been a regression* and I can confirm this bug's status is now incorrect. It should active as of 2016-07-28.
*(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.
*(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
#6, could you please provide us any guidance how to reproduce this?
I've tried this on iOS safari and on a MacbookPro with Safari 11601.7.7 loading this page:
https://developers.google.com/maps/documentation/javascript/examples/map-simple
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.
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.