Closed
Bug 631848
Opened 14 years ago
Closed 14 years ago
status panel causes artifact during page loading
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: tnikkel, Assigned: tnikkel)
References
()
Details
Attachments
(2 files)
1.31 KB,
patch
|
roc
:
review+
roc
:
approval2.0+
|
Details | Diff | Splinter Review |
327.12 KB,
image/jpeg
|
Details |
Every time I load http://www.ourbombers.com on Linux or Windows I get a dark blue artifact around the status panel just before the page contents show up.
I know why it happens. I don't know what to do about it.
Assignee | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Assignee | ||
Comment 1•14 years ago
|
||
So the basic problem here is that we don't send an invalidate when what we paint changes. In this case we don't get an invalidate when we go from drawing the previous page's view to using the new page's view. In this case the removal of the previous page's root view in DocumentViewerImpl::Destroy does not cause an invalidate. This is because the PresShell::Freeze just just above in that function sets painting to be suppressed on that document, so the invalidate that the view removal causes just dies. The obvious fix is to just make sure that invalidate happens using a flag or something to force it.
There is a time period when loading a new page where we have a choice for what to draw. (1) We can draw the previous page. (2) Or we can draw the background color only of the new page (even if the new page has some content). In bug 593892 I changed us from doing (1) to doing (2) to fix a bug. No one seems to have noticed or complained. But with this bug fixed we could do (1) or (2). (If we went with (1) we'd have to invalidate in PresShell::InitialReflow where we create the root frame.)
Assignee | ||
Comment 2•14 years ago
|
||
Assignee: nobody → tnikkel
Attachment #510176 -
Flags: review?(roc)
Attachment #510176 -
Flags: approval2.0?
Attachment #510176 -
Flags: review?(roc)
Attachment #510176 -
Flags: review+
Attachment #510176 -
Flags: approval2.0?
Attachment #510176 -
Flags: approval2.0+
blocking2.0: ? → final+
Assignee | ||
Comment 3•14 years ago
|
||
I tryservered this, ready to land.
Keywords: checkin-needed
Whiteboard: [needs landing]
Assignee | ||
Comment 4•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing]
Comment 5•14 years ago
|
||
Is this what you were talking about? This still happens on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110216 Firefox/4.0b12pre
Assignee | ||
Comment 6•14 years ago
|
||
Nope, that is not what this bug was about. That happens at least as far back as Firefox 3.6.
You need to log in
before you can comment on or make changes to this bug.
Description
•