Bug 214945 – First search on Google Maps shows black bar at top of map and blank strips through the middle

• Status: RESOLVED
• Resolution: FIXED
• Component: WebGL

[Dean Jackson]

* SUMMARY
- First search on Google Maps shows black bar at top of map and blank strips through the middle

* STEPS TO REPRODUCE
1. Navigate to https://maps.google.com/
2. Search for a location (e.g. Cupertino, CA)
3. Review Maps

* EXPECTED RESULTS
- No visual anomalies

* ACTUAL RESULTS
- Blank bar at top of mmap
- Blank strips through the middle of the map

Extra notes:
- reproduces on an iPad Pro with a bluetooth or magic keyboard attached!
- sometimes the lines are blank, other times black
- usually only happens on a first search, but i've had luck with the following flow:
  + search for Cupertino (map navigates to there)
  + search for Sunnyvale (map pans and might leave blank strips)
  + the fact that it only had to pan a bit seems important

[Dean Jackson]

<rdar://problem/63374422>

[Dean Jackson]

Created attachment 405517 [details]
Screenshot

[Kenneth Russell]

Could this be related to earlier Google Maps-related bugs with the ANGLE backend, Bug 208331 and Bug 210992?

A significant ANGLE roll was just done in Bug 214897 - possible to re-test on top of that?

[James Darpinian]

Looking at the screenshot it appears something went wrong with tile clipping. In Google Maps tiles can be clipped using either the stencil buffer or the scissor rect. If I had to guess I would say that it is probably using the stencil buffer in this case. Each tile is assigned a unique stencil value and the stencil buffer is filled with these values in a pass that happens first, before other things are drawn. It looks to me as though there is an erroneous vertical offset being applied during the stencil pass, and then subsequent drawing of roads is being clipped incorrectly by the incorrect stencil buffer.

[Dean Jackson]

Updating bugzilla. This is not a regression in iOS 14, and likely not related to WebGL.

I'll attach a screen recording and two frames as static images. It appears that what is happening is Google Maps selects a (destination?) viewport when the keyboard accessory bar is visible, animates to the searched location, and doesn't realise that the accessory bar is now hidden (and thus the viewport has changed). Or, more specifically, one part of the app doesn't notice this, since you can see in the two frames (which are adjacent in the timeline) that it does decide to squish its zoom ratio in the horizontal axis.

[Dean Jackson]

Created attachment 406336 [details]
screen recording

[Dean Jackson]

Created attachment 406337 [details]
Frame A

[Dean Jackson]

Created attachment 406338 [details]
Frame A+1

[Dean Jackson]

Notice that the horizontal viewing area changes between A and A+1 but the vertical does not.

(Also funny that two PNGs taken from the video end up larger than the video itself)

[Dean Jackson]

Created attachment 406486 [details]
Patch

[Dean Jackson]

Committed r265581: <https://trac.webkit.org/changeset/265581>

[Darin Adler]

Comment on attachment 406486 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=406486&action=review

> Source/WebCore/ChangeLog:19
> +        Rather than have Google Maps update its code to detect these viewport changes,
> +        we're adding a Quirk to not use the control bar in these calculations.

This sounds like it’s our forever solution. Do you mean, "Until Google Maps updates its code"?

[Dean Jackson]

(In reply to Darin Adler from comment #12)
> Comment on attachment 406486 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=406486&action=review
> 
> > Source/WebCore/ChangeLog:19
> > +        Rather than have Google Maps update its code to detect these viewport changes,
> > +        we're adding a Quirk to not use the control bar in these calculations.
> 
> This sounds like it’s our forever solution. Do you mean, "Until Google Maps
> updates its code"?

Yes, that's what I meant. Google Maps could fix this on their end, but this solves it for now. I'll email contacts there to encourage them, but they'll now have to use iOS 13 to test a fix.