White rectangle visible for a short time over acid3 test when reloading

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Kai de Leeuw, Assigned: tnikkel)

Tracking

unspecified
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: regression, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100902 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100902 Firefox/4.0b6pre

Summary is enough.

Reproducible: Always

Steps to Reproduce:
1. Open http://acid3.acidtests.org/
2. When finished counting up to 97 press the reload button
3. Behold the white rectangle that is visible for a short time and then disappears
Actual Results:  
White rectangle over acid3 test.

Expected Results:  
No white rectangle over acid3 test.
(Reporter)

Comment 1

8 years ago
The rectangle also shows when you navigate to another page.

Comment 2

8 years ago
Kai, do you have any regression date for this?
Whiteboard: regression
Keywords: regressionwindow-wanted
(Assignee)

Comment 3

8 years ago
Probably caused by bug 130078.
Blocks: 130078
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regressionwindow-wanted
(Assignee)

Comment 4

8 years ago
Created attachment 472502 [details]
reduced testcase
Assignee: nobody → tnikkel
(Assignee)

Comment 5

8 years ago
There is a (transparent) iframe (well actually an object with data attribute that points to an html document) in the acid3 test, which is basically all you need to reproduce this. When we create the content viewer for the new document the mParent pointer on the docshell for the iframe gets nulled out (via the path nsDocShell::CreateContentViewer -> Embed -> SetupNewViewer -> DestroyChildren). But we still draw the old page for a while yet.

When we call nsContentUtils::IsChildOfSameType in PresShell::UpdateCanvasBackground (for an opaque bg color on the root content document) and nsSubDocumentFrame::BuildDisplayList (for a container layer on the root content document) it returns null because the parent pointer is null, not because it is the root content document.

So I think for drawing purposes, we need to look at the frames/views for this purpose, not the docshell.
(Assignee)

Comment 6

8 years ago
Created attachment 472503 [details] [diff] [review]
patch
Attachment #472503 - Flags: review?(roc)
(Assignee)

Updated

8 years ago
Attachment #472503 - Flags: approval2.0?
(Assignee)

Comment 7

8 years ago
Created attachment 472786 [details] [diff] [review]
patch v2

We need to return a correct value even when we don't have a root frame. The only thing different in this patch is the definition of IsRootContentDocument.
Attachment #472503 - Attachment is obsolete: true
Attachment #472786 - Flags: review?(roc)
Attachment #472503 - Flags: approval2.0?
Comment on attachment 472786 [details] [diff] [review]
patch v2

Prefer vm over VM
Attachment #472786 - Flags: review?(roc) → review+
(Assignee)

Updated

8 years ago
Attachment #472786 - Flags: approval2.0?
(Assignee)

Updated

8 years ago
Attachment #472786 - Flags: approval2.0?
(Assignee)

Comment 9

8 years ago
http://hg.mozilla.org/mozilla-central/rev/588f3801b693
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
Depends on: 602794
You need to log in before you can comment on or make changes to this bug.