Bug 214945

Summary: First search on Google Maps shows black bar at top of map and blank strips through the middle
Product: WebKit Reporter: Dean Jackson <dino>
Component: WebGLAssignee: Dean Jackson <dino>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, dino, jdarpinian, jonahr, kbr, mmaxfield, thorton, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 208331, 210992, 214897    
Bug Blocks:    
Attachments:
Description Flags
Screenshot
none
screen recording
none
Frame A
none
Frame A+1
none
Patch thorton: review+

Dean Jackson
Reported 2020-07-29 15:38:00 PDT
* 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
Attachments
Screenshot (3.98 MB, image/png)
2020-07-29 15:41 PDT, Dean Jackson 		no flags
Details
screen recording (5.43 MB, video/quicktime)
2020-08-10 16:08 PDT, Dean Jackson 		no flags
Details
Frame A (3.45 MB, image/png)
2020-08-10 16:09 PDT, Dean Jackson 		no flags
Details
Frame A+1 (3.14 MB, image/png)
2020-08-10 16:09 PDT, Dean Jackson 		no flags
Details
Patch (2.63 KB, patch)
2020-08-12 18:00 PDT, Dean Jackson 		thorton: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Dean Jackson
Comment 1 2020-07-29 15:39:42 PDT
<rdar://problem/63374422>
Dean Jackson
Comment 2 2020-07-29 15:41:22 PDT
Created attachment 405517 [details] Screenshot
Kenneth Russell
Comment 3 2020-07-29 16:30:52 PDT
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
Comment 4 2020-07-30 14:37:38 PDT
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
Comment 5 2020-08-10 16:07:41 PDT
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
Comment 6 2020-08-10 16:08:33 PDT
Created attachment 406336 [details] screen recording
Dean Jackson
Comment 7 2020-08-10 16:09:22 PDT
Created attachment 406337 [details] Frame A
Dean Jackson
Comment 8 2020-08-10 16:09:53 PDT
Created attachment 406338 [details] Frame A+1
Dean Jackson
Comment 9 2020-08-10 16:10:52 PDT
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
Comment 10 2020-08-12 18:00:04 PDT
Created attachment 406486 [details] Patch
Dean Jackson
Comment 11 2020-08-12 19:08:32 PDT
Committed r265581: <https://trac.webkit.org/changeset/265581>
Darin Adler
Comment 12 2020-08-12 19:22:23 PDT
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
Comment 13 2020-08-14 02:09:03 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.