Closed Bug 374038 Opened 14 years ago Closed 14 years ago

[FIX]Canvas layout in XUL broken with XulRunner 1.9

Categories

(Core :: Canvas: 2D, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9alpha4

People

(Reporter: murlock42, Assigned: bzbarsky)

References

Details

(Keywords: regression, testcase)

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/2007-03-14-08-trunk/

With all releases of XulRunner 1.9 (a1 throught a3), the testcase show a little window with no content instead of a little text with a canvas.

Reproducible: Always

Steps to Reproduce:
1. Open the testcase

Actual Results:  
The content of windows show the background content and the canvas has a size of zero. http://murlock.org/xul/xul_19a3.png

Expected Results:  
With XulRunner 1.8.0.4, the windows look like that : http://murlock.org/xul/xul_1804.png

It may be related to http://bugzilla.mozilla.org/show_bug.cgi?id=366616
Attached file Show the bug
This looks to be unrelated to the canvas element to me. In the screenshot given no part of the window displays, not even the description at the top.

How are you opening this window?
This is definitely a bug. With the landing of the reflow branch, the canvas element doesn't show up anymore.
Between 2007-01-16 and 2007-01-17, the whole page doesn't get shown at all, instead the previous contents stays painted. This is rather bad.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Keywords: regression, testcase
Attached file testcase2
Flags: blocking1.9? → blocking1.9+
There are basically two parts to this patch:

1)  Make BoxReflow() actually compute an mComputedHeight using ComputeSize as
    needed.  This is necessary because replaced elements just use the
    mComputedHeight as their height, and the reflow state is not calling
    ComputeSize because it thinks it's a reflow root (no parent reflow state).
    I suppose this call could also be moved into the reflow state.
2)  Change the computation of the boxmetrics mBlockMinSize to set _something_
    nonzero for non-block kids of XUL boxes.  Using whatever height came back
    from BoxReflow in this case seems to make sense to me.  If I don't do this,
    then I get a zero-height canvas, because after reflowing the kid sprocket
    layout clobbers its rect with the stuff hanging out in the boxmetrics.

David, thoughts?  It's a little hacky, but....
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #260210 - Flags: superreview?(dbaron)
Attachment #260210 - Flags: review?(dbaron)
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Summary: Canvas broken with XulRunner 1.9 → [FIX]Canvas layout in XUL broken with XulRunner 1.9
Target Milestone: --- → mozilla1.9alpha4
Comment on attachment 260210 [details] [diff] [review]
Possible approach

r+sr=dbaron
Attachment #260210 - Flags: superreview?(dbaron)
Attachment #260210 - Flags: superreview+
Attachment #260210 - Flags: review?(dbaron)
Attachment #260210 - Flags: review+
Flags: in-testsuite?
Attached patch Regression testSplinter Review
Fixed.
Flags: in-testsuite? → in-testsuite+
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Duplicate of this bug: 368137
v.fixed

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050704 Minefield/3.0pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.