Open Bug 2009486 Opened 4 months ago Updated 3 months ago

Text on Google Maps briefly disappears & reappears when zooming out the map with mouswheel

Categories

(Web Compatibility :: Site Reports, defect, P3)

Product:
Web Compatibility
Component:
Site Reports
Type:
defect

Tracking

(Webcompat Priority:P3, Webcompat Score:2)

Project Flags:
Webcompat Priority P3
Webcompat Score 2

People

(Reporter: dholbert, Unassigned)

References

(Depends on 2 open bugs,
URL
)

Details

(Keywords: webcompat:contact-in-progress, webcompat:platform-bug, webcompat:site-report, Whiteboard: [webcompat:sightline][webcompat:japan][webcompat:core])

User Story

platform:windows,mac,linux
impact:minor-visual
configuration:general
affects:all
branch:release
diagnosis-team:webcompat
user-impact-score:15

Attachments

(3 files)

screencast showing the bug in Firefox 146.0.1, vs. no-bug when I spoof as Chrome with Chrome Mask extension
6.03 MB, video/mp4
Details
screenshot showing the bug (from around t=3s in the screencast, when all the text street-labels have briefly disappeared as I zoom out)
300.38 KB, image/jpeg
Details
screencast of bug reproducing in Chrome-spoofing-a-Firefox-UA-string
2.86 MB, video/mp4
Details

STR:

  1. Visit https://www.google.com/maps/place/San+Francisco,+CA/@37.7531131,-122.433937,16z/data=!4m6!3m5!1s0x80859a6d00690021:0x4a501367f076adff!8m2!3d37.7749295!4d-122.4194155!16zL20vMGQ2bHA?entry=ttu&g_ep=EgoyMDI2MDEwNy4wIKXMDSoASAFQAw%3D%3D (Google Maps viewing 23rd & Castro St, San Francisco, CA -- this is just an example of one affected spot, but the issue is not specific to this spot.)

  2. Zoom in & out (using mousewheel) around zoom levels that are not-quite-zoomed-in-enough to show the boundaries of individual buildings on the block. Find a threshold between two zoom "ticks" where the street names (e.g. 22nd, 23rd) change their horizontal position along their block between the two zoom levels.

  3. Go back and forth between those two zoom levels, watch the text carefully.

ACTUAL RESULTS:
Specifically when you zoom out, various text labels (street names, mostly) disappear for a few moments before reappearing at a new location.

EXPECTED RESULTS:
No such disappearing text. If the text needs to move, it atomically reappear at its new location.

I can reproduce in Firefox Nightly 148.0a1 (2026-01-09) (64-bit) as well as Firefox Release 146.0.1.
I cannot reproduce in Chrome, nor can I reproduce if I spoof as Chrome from the above-mentioned Firefox versions with the Chrome ask add-on.

Hence, this seems to come down to UA-sniffing, where the version of Google Maps that's served to Firefox is affected by this bug, whereas the version that's served to Chrome is not.

Attachment #9536730 - Attachment description: screenshot showing the bug (from around t=3s in the screencast, when all the text street-labels have briefly disappeared as I zoom out)( → screenshot showing the bug (from around t=3s in the screencast, when all the text street-labels have briefly disappeared as I zoom out)

I haven't noticed this before, so I have a suspicion that this only broke recently.

I don't think anything broke on Firefox's end; I can reproduce this in Firefox Nightly from a year ago (Nightly 2025-01-01 v135.0a1).

So I suspect something might have changed recently in the version-of-Google-Maps-that-gets-served-to-Firefox-users, which introduced this bug. But again, I'm not sure.

I'll reach out to our Google partner list to see if they can have someone take a look at this...

(In reply to Daniel Holbert [:dholbert] from comment #0)

I can reproduce in Firefox Nightly 148.0a1 (2026-01-09) (64-bit) as well as Firefox Release 146.0.1.
I cannot reproduce in Chrome, nor can I reproduce if I spoof as Chrome from the above-mentioned Firefox versions with the Chrome ask add-on.

Also notably, I can reproduce in Chrome if I spoof a Firefox UA-string.

So: the Firefox/Chrome behavior-difference here is entirely due to Google Maps serving a different version of the site depending on your UA string.

(I reached out to our Google discussion-list.)

URL: https://www.google.com/maps/
Severity: -- → S4
User Story: (updated)
Webcompat Priority: --- → P3
Webcompat Score: --- → 2
Keywords: webcompat:contact-in-progress, webcompat:site-report
Priority: -- → P3
Whiteboard: [webcompat:sightline][webcompat:japan]

Google is updating how we render maps on the web to support future improvements, and we've launched our new renderer on Chrome. The version served to Chrome has changed and Firefox is still using our previous renderer.

We've identified https://bugzilla.mozilla.org/show_bug.cgi?id=1736076 and https://bugzilla.mozilla.org/show_bug.cgi?id=918941 as issues that are blocking us from bringing the new renderer to Firefox. Please fix these issues.

Depends on: 1736076, webgl-shader-cache
Keywords: webcompat:platform-bug

Thanks, Mike! Good to understand the behavior-difference here.

+CC ahale who's involved with our WebGL implementation. (ahale, see comment 5 for some WebGL bugs that would be good to address to get the same improved experience that Chrome is currently getting on Google Maps.)

(Side note, I worried that bug 833623 might be a problem here too, but it seems I am able to print from Google Maps even when spoofing as Chrome to get the new experience; so I assume Google is falling back to a 2d canvas when printing, or we're avoiding that bug somehow.)

Supporting the new Maps renderer sounds like a very good thing to do, will discuss how we can fit it into plans.

See Also: → 2016057
Whiteboard: [webcompat:sightline][webcompat:japan] → [webcompat:sightline][webcompat:japan][webcompat:core]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: