387486 - XUL tree / editor element within a xul grid breaks the window

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Asaf Romano (gone)]

XUL editor element within a xul grid breaks the window.

1. Apply the WIP patch in bug 387485, on a mac.
2. Accel+D
3. Notice the right-hand column width.

Comment 1

[Neil Deakin]

Attachment: reduced testcase

The editor here is causing box layout to overflow:

###!!! ASSERTION: A Box's child is constantly growing!!!!!: 'passes < 10', file /builds/trunk-places/mozilla/layout/xul/base/src/nsSprocketLayout.cpp, line 627

Will investigate some more. The align="center" as well as the -moz-appearance: textfield seem necessary as well

Comment 2

[Neil Deakin]

The same issue occurs if any inline element with a -moz-appearance is used instead of an editor.

Looks like a problem where the size of an inline inside a box is getting its minimum/prefered width calculated with some extra size to account for the native theme (margin / minsize / border, haven't determined what), yet when Layout is called, this size is not being included, causing the the sprocket layout code to think the size has changed. This causes a loop.

Also, this issue doesn't seem to occur in 1.8, so I suspect a reflow branch regression.
 

Comment 3

[Asaf Romano (gone)]

I see this with xul trees as well now.

Comment 4

[Asaf Romano (gone)]

Though, my tree is a direct child of the containing grid (in-between <row> elements).

Comment 5

[Neil Deakin]

This is a regression from bug 370659 caused because an overflow rect is being included. Commenting out the code in nsNativeThemeCocoa::GetWidgetOverflow fixes this bug. That code is actually correct though.

The issue is in nsFrame::BoxReflow which is called twice, once to calculate the min/max/pref width and the other during reflow. In the former case, the NS_FRAME_OUTSIDE_CHILDREN bit isn't yet set, but in the latter it is which causes the overflow rect to be added to the desired size. I'm not sure what this code is for or why the overflow area is being added to the size though.

Comment 6

[Neil Deakin]

Attachment: simple change

This isn't really the right patch, but a simple fix is to just ignore the native theme overflow for box wrapped blocks. This does mean that this small number of pixels might get cut off in this very unlikely case where an inline or block has a moz-appearance set, but that would be easier to workaround than it would be to fix how overflow on boxes works.

Comment 7

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

See bug 375180.

I'm fine with taking this patch as a workaround.

Comment 8

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

This does mean that HTML form elements with native theming that get wrapped as XUL boxes won't include the overflow, and possibly similar issues with XUL elements inside HTML containers inside a box context --- all these could experience painting/invalidation problems.

I wonder which of the patch in bug 375180 and the patch here is the lesser of the two evils.

Comment 9

[Neil Deakin]

Roc, I think that unless we have a better idea, we should take this patch for M8 so we can get some testing. The only difference I've seen from testing is that there is a smaller gap around a native themed block. Also, this only affects Mac as neither Windows/Linux native themes include an extra overflow area (except Linux scrollbuttons)