321751 - Calling Alert() in header causes background of page not to render

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Andrew Wooldridge]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Background color is not rendered completly when an intial alert dialog comes up.

Reproducible: Always

Steps to Reproduce:
1.Load http://andrewwooldridge.com/testingstuff/bgbug.html
2.click the alert ok
3.view the resulting page


Actual Results:  
The words "hello" are colored tan. The rest of the page is white.

Expected Results:  
The entire page should be tan.

The page will suddenly be the right background color if you resize the window.

Comment 1

[Andrew Wooldridge]

Attachment: html file that demos the problem

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

Confirming with trunk build 2005-12-28-08 of SeaMonkey on Windows XP.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

Note that if you get a context menu anywhere on the page that results, its former popup area will be painted with the correct background color.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So we're somehow managing to not invalidate the canvas area when we insert the new body; I wonder why.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So yeah, this is a regression from bug 253951.  But even before that patch, there was a problem -- just try loading the following URI in an about:blank document -- the background should become green, but doesn't...

javascript:document.documentElement.removeChild(document.body); var bod = document.createElement("body"); bod.setAttribute("bgcolor", "#00ff00"); void(document.documentElement.appendChild(bod))

I suppose we could do the same things in ContentAppended/Inserted/Removed as we do in RecreateFramesForContent in terms of looking to see whether the background is propagated to the canvas, etc...  Is there a better idea, though?  roc?  David?  Mats?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase from comment 5

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed patch

Summary of changes:

1)  Remove some aPresContext and unused aViewManager params
2)  Add a new method to handle invalidation and call it in
    ContentAppended/Inserted/Removed
3)  Remove the invalidate in RecreateFramesForContent (it's handled by the other
    code now)

Note that I had to leave part of the FindBackground stuff, because I wasn't sure how else to find the right frame to invalidate...

Comment 8

[Boris Zbarsky [:bzbarsky]]

Another testcase (that is not regressed): in a blank document, run:

javascript:var s = document.body.style; void(s.cssText = "display:inline; background: green")

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+ * This method invalidates the canvas when frames are reconstructed for a node

I think "removed or added" instead of "reconstructed"

+ * that might have its background propagated to the canvas.

I would add ", i.e., a document root node or an HTML BODY which is a child of the root node".

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Updated to comments.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 12

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using both testcases under SeaMonkey 1.5a;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060116 Mozilla/1.0.

Comment 13

[Ria Klaassen (not reading all bugmail)]

*** Bug 362366 has been marked as a duplicate of this bug. ***