Closed Bug 1128860 Opened 10 years ago Closed 10 years ago

mixed content with canvas (e.g. Google Streetview) results in incorrect rendering

Categories

(Core :: Graphics: Canvas2D, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1034593

People

(Reporter: winter-mozilla, Unassigned)

Details

Attachments

(5 files, 1 obsolete file)

Hi, when using Google Streetview on the "new" Google Maps interface using the canvas element instead of traditional img tags for tiles, I experience severe rendering issues rendering the application almost useless. https://www.google.com/maps/@48.098542,11.580336,3a,75y,40.68h,63.31t/data=!3m4!1e1!3m2!1s71iIrPz23m64vqDVt1NyJQ!2e0?hl=de When first visiting the page, everything is fine. Changing the "view" inside the Streetview widget works as well. However, when one cliks on a direction arrow to "move" around, strange things start to happen: 1.) the "movement" animation starts, and stops in the middle, no more progress (seldom) 2.) the viewport is fully covered by the canvas background color (grey; I changed the CSS attribute and can therefore verify that it is indeed the background color of the canvas), even covering elements with higher z-index (like the watermark); however when the picture gallery at the bottom is shown, this area normally stays intact (this happens almost always) 3.) it works (very seldom) I inspected the DOM of the Google Maps website and cannot explain why the canvas element would cover other elements with higher z-index (without refering to this behaviour as a bug). However as a workaround I found out, that resizing the window triggers dimension changes to the canvas elements and such (supposedly by the JavaScript of Google Maps) and finally a redraw. When changing dimensions of the canvas the old context will be destroyed which might cause the problem. After the redraw everything is fine again and one can see that Google Maps actually executed the command (of "movement" on the street) one demanded. I investigated further when editing the DOM to extend the width via CSS in order to get scroll bars, I thought I could also the trigger the redraw. Similarly when viewing the "gray area" (background color of canvas) I clicked on the button for buttom picture view widget and sometimes the widget would then be shown. However when moving the mouse around, non-deterministically elements which should have been displayed at top level, would show up and/or disappear. I assume the rendering context at this point is broken. However I expect this problem hard to reproduce as I am using low-end hardware which results in rather poor canvas performance. Maybe the canvas redrawing is so slow that it misses some rendering deadline and therefore the result will never be flushed. Best regards, Leon Winter
I should clarify that I am not using the Street View version with Flash but the version entirely written in JavaScript and using canvas as drawing backend
Comment on attachment 8558391 [details] Most frequent incorrect rendering result (gray=canvas.style.background) wrong picture
Attachment #8558391 - Attachment is obsolete: true
I have been modifying the DOM further to narrow down the origin of this behaviour. It is now clear that the buggy rendering behaviour originates from the canvas element. When changing DOM CSS proporties of the canvas element (like background and border) they are correctly rendered. However in this "broken" state the viewport of the canvas will corrupt the rendering of supposedly overlaying elements (as defined by z-index in CSS) and simply draw its own background color instead of showing those elements. Also I have been trying to inject canvas drawing commands via the console to no avail. While in "healthy mode", I can draw stuff on the canvas surface, in the broken state no drawing operation will yield a result. This further establishes the assumption that the drawing operations will be correctly executes in the display buffer for the canvas element, yet it will not be rendered to the screen. Even worse appearently the "exposed" area the canvas occupied will be corrupted for all DOM elements which might also be placed in this area.
Component: Layout: View Rendering → Canvas: 2D
Problem is gone with version 35, I highly suspect it is the bug mentioned. The commit description surely sounds like the problem, too. It is a shame though the ESR release will not get this fix because it is not security related. This basically means Google Streetview ist not usuable until the next major ESR release :(
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
So, just to be sure I bisected (releases) and it turns out, that it was not the bug I marked duplicate but it must be another one. The last broken version for me is 31.0, the first working version is 32.0b1 so the bug was fixed either on 22nd or 23rd of July 2014. It should be noted however that the bug as I originally described is not occuring with 31.0. Instead of displaying the background color, 31.0 gets "further" in the rendering process but then gets "stuck". No further interaction is possible. Resizing the window fixes the situation. This of course means there is another partial bugfix in the versions before which results in the canvas element drawing stuff instead of just its background color. I am not sure how this related to the latter part of correct redrawing which I narrowed down to a version change.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
I checked the commits in the corresponding time frame and general commits regarding canvas and found the culprit, now marking this bug duplicate. I can confirm that applying the commit on 31.4.0esr yields a working Google Streetview :)
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: