Box layout does not provide consistent sizes

VERIFIED FIXED in M14

Status

()

Core
XUL
P1
blocker
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: rods (gone), Assigned: Eric Vaughan)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] 3/03/00 rod to verify)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
Box layout is not providing the combobox with a consistent sizes for 
aReflowState.mComputedWidth (or availableWidth). When the mail compose window 
displays the last mComputedWidth size as the the "From" Combobox gets layed 
out it is "4269", then on a mouse down the mComputedWidth is "5022".

The 5022 is an incremental reflow targeted at the ListControlFrame that is a 
child (popup list child so it doesn't get reflowed automatically) of the 
ComboboxControlFrame. In normal HTML layout the incoming mComputedWidth and 
availableWidth are both UNCONSTRAINED.

Here is my debug output:
nsCCF - nsComboboxControlFrame
nsLCF - nsListControlFrame
----------------------------------------------------
OnEndDocumentLoad
03C5F98C ** nsCCF::Reflow 15 R: Resize AW: 4329 AH: UNC CW: 4269 CH: 270 NO: 2 *

**Constrained WW: 4029  HH: 240
DW: 345
03C5FA54 ** nsLCF::Reflow 19 R: Resize AW: 345 AH: UNC CW: 345 CH: UNC
** Done nsLCF DW: 345  DH: 540
[[[[ CW: 4269 30 30
** Done nsCCF DW: 4329  DH: 330
Lost focus.
nsWebShellWindow::GOTFOCUS
set focus on the recipient
WEBSHELL+ = 7
Lost focus.
Lost focus.
nsWebShellWindow::GOTFOCUS
--------------------------- MouseDown ----------------------------
03C5F98C ** nsCCF::Reflow 16 R: Increm AW: 5082 AH: UNC CW: 5022 CH: 270 NO: 2 *

-----------------Target is Dropdown or it's child------------
03C5FA54 ** nsLCF::Reflow 20 R: StyleC AW: UNC AH: UNC CW: UNC CH: UNC
** Done nsLCF DW: 3675  DH: 540
|** Done nsCCF DW: 4329  DH: 330
--------------------------- MouseUp ----------------------------
03C5F98C ** nsCCF::Reflow 17 R: Increm AW: 5082 AH: UNC CW: 5022 CH: 270 NO: 2 *

-----------------Target is Dropdown or it's child------------
03C5FA54 ** nsLCF::Reflow 21 R: StyleC AW: UNC AH: UNC CW: UNC CH: UNC
** Done nsLCF DW: 3675  DH: 540
|** Done nsCCF DW: 4329  DH: 330
--------------------------- MouseUp ----------------------------
Lost focus.

Comment 1

18 years ago
reassign to hyatt until evaughan gets back, cc evaughan. 
Assignee: trudelle → hyatt

Comment 2

18 years ago
Rod, I thought you said this was a blocker.  If so, please set severity 
accordingly, and add beta1 keyword.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M14

Comment 3

18 years ago
Eric can deal with this when he returns from vacation.  I'm not comfortable 
trying to fix the box code when it just got rewritten.
Assignee: hyatt → evaughan
Status: ASSIGNED → NEW
(Reporter)

Comment 4

18 years ago
*** Bug 28463 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 5

18 years ago
I am blocked by this bug for my PDT+ bug, adding hyatt and trudelle to cc list
Severity: normal → blocker
Keywords: beta1
(Reporter)

Comment 6

18 years ago
*** Bug 28656 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 7

18 years ago
forgot to document that I changed it to beta1 and "blocker"
(Reporter)

Updated

18 years ago
Blocks: 27881
(Reporter)

Comment 8

18 years ago
added 27881 as a dependency

Comment 9

18 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
(Reporter)

Comment 10

18 years ago
I have worked around a few of the issues, but I am not blocked by this:

When an item gets added to an option in XUL via RDF and and the dialog is using 
box layout. An incremental reflow is generated for the option (item) and the 
incremental reflow comes in with avilableWidth/height and mComputedWidth/Height 
set to the value of the last reflow when the combobox had no items. Eventually, 
a resize reflow comes through with the correct values, but it is still causing 
problems.

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+]UNKNOWN- on vacation

Comment 11

18 years ago
Don't you mean "but I _am_ blocked by this:"?
Priority: P3 → P1
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Whiteboard: [PDT+]UNKNOWN- on vacation → [PDT+] 2/25/00 Currently working with rod on this.
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] 2/25/00 Currently working with rod on this. → [PDT+] 2/25/00 Have fix working with rod.
(Assignee)

Comment 12

18 years ago
fixed
(Assignee)

Comment 13

18 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 14

18 years ago
I am now sizing correctly to 2925 twips or 195 pixels which matches the 
horizontal spring for the example I will attach.

The problem is: when I click on the combobox I first correctly get an 
unconstrained incremental reflow and then (wrongly) I get an dirty reflow with 
the availWidth and computed width set to 3117 twips or 207.8 pixels. This value 
is wrong. This is what I have always been seeing. The mouse down reflows with 
the wrong computed and avilable size.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 15

18 years ago
Created attachment 5772 [details]
better XUL example
(Reporter)

Comment 16

18 years ago
If you need to test with my tree, go to spears-3 and grab these directories:
layout\html\forms
layout\html\content
layout\html\style
(Reporter)

Comment 17

18 years ago
Created attachment 5773 [details] [diff] [review]
patch file for my current layout changes
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] 2/25/00 Have fix working with rod. → [PDT+] 3/03/00 Have fix working with rod.
(Reporter)

Comment 18

18 years ago
On MouseDown and MouseUp in HTML layout I just get an Inremental reflow, in Box 
I get Incremental and then a Dirty. 
Not only do I NOT need the Dirty it is the one that is sending me the wrong 
size.
(Assignee)

Comment 19

18 years ago
Rods stuff now works.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 20

18 years ago
spam: QA contact to jrgm (PDT+ resolved to be verified)
QA Contact: paulmac → jrgm

Comment 21

18 years ago
rods : can you verify that this is now working correctly. Thanks.
Whiteboard: [PDT+] 3/03/00 Have fix working with rod. → [PDT+] 3/03/00 rod to verify
(Reporter)

Comment 22

18 years ago
As far as I can tell this is fixed.

Comment 23

18 years ago
Thanks Rod. marking verified.
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.