Closed
Bug 28460
Opened 25 years ago
Closed 25 years ago
Box layout does not provide consistent sizes
Categories
(Core :: XUL, defect, P1)
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: rods, Assigned: eric)
References
Details
(Whiteboard: [PDT+] 3/03/00 rod to verify)
Attachments
(2 files)
3.20 KB,
text/plain
|
Details | |
132.26 KB,
patch
|
Details | Diff | Splinter Review |
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•25 years ago
|
||
reassign to hyatt until evaughan gets back, cc evaughan.
Assignee: trudelle → hyatt
Comment 2•25 years ago
|
||
Rod, I thought you said this was a blocker. If so, please set severity accordingly, and add beta1 keyword.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M14
Comment 3•25 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 5•25 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 7•25 years ago
|
||
forgot to document that I changed it to beta1 and "blocker"
Reporter | ||
Comment 8•25 years ago
|
||
added 27881 as a dependency
Reporter | ||
Comment 10•25 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•25 years ago
|
Whiteboard: [PDT+] → [PDT+]UNKNOWN- on vacation
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [PDT+]UNKNOWN- on vacation → [PDT+] 2/25/00 Currently working with rod on this.
Assignee | ||
Updated•25 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•25 years ago
|
||
fixed
Assignee | ||
Comment 13•25 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 14•25 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•25 years ago
|
||
Reporter | ||
Comment 16•25 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•25 years ago
|
||
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] 2/25/00 Have fix working with rod. → [PDT+] 3/03/00 Have fix working with rod.
Reporter | ||
Comment 18•25 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•25 years ago
|
||
Rods stuff now works.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 20•25 years ago
|
||
spam: QA contact to jrgm (PDT+ resolved to be verified)
QA Contact: paulmac → jrgm
Comment 21•25 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•25 years ago
|
||
As far as I can tell this is fixed.
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.
Description
•