375180 - Odd sizing behavior for html tags in XUL with outlines

Status: NEW

(Core :: Layout, defect)

Description

[Eli Friedman]

Attachment: Testcase

Per description; testcase+patch coming up.

Comment 1

[Eli Friedman]

Attachment: Patch

I'm not sure what this chunk of code was intended to do; probably a workaround for some bug in XUL overflow support. (I can't say for sure since the code has been there since version 1.1 of nsBoxToBlockAdaptor.cpp.)  It seems completely bogus, though, and XUL can deal with overflow in the current codebase.

Comment 2

[Eli Friedman]

(Of course, the first bit is from Bug 372037, and isn't relevant.)

Comment 3

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

This changes behavior of HTML-in-XUL in quite a big way. How can we be sure that this won't break XUL users?

Comment 4

[Eli Friedman]

(In reply to comment #3)
> This changes behavior of HTML-in-XUL in quite a big way. How can we be sure
> that this won't break XUL users?

Excluding form controls, HTML-in-XUL isn't very common, and hopefully overflowing HTML-in-XUL is very rare.  The only case I can imagine content depending upon would be positioned children forcing the parent to resize.

If you think this is too risky, though, we can put it off to Gecko 2.0.

Comment 5

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

Yeah, I think we should put this on ice for now.

Comment 6

[Eli Friedman]

Comment on attachment 259501 [details] [diff] [review]
Patch

Okay then; iced until 1.9 branches.

Comment 7

[Neil Deakin]

Attachment: testcase

Removing the overflow code completely causes blocks in boxes to be sized incorrectly in some cases. Does this following testcase work?

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.