414851 - CSS whitespace: nowrap not respected when inherited from a cell by a button

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[jsp]

Attachment: testcase

According to the CSS 2.1 specification, the value of the whitespace property is inherited.  This has broken in one case in Firefox 3 beta 2: when a button is contained in a cell.  If the cell specifies nowrap, any text in the button should not wrap, but it does.

This appears to be specific to the button-in-a-cell case, since whitespace: nowrap is respected in the following scenarios:
- nowrap is specified on the button directly
- rather than a button, a div is the contained element
- rather than a cell, a span is the containing element
- rather than a cell, a floated div is the containing element

Comment 1

[Jesse Ruderman]

According to DOM Inspector, the button's computed white-space value is "normal" because resource://gre/res/forms.css contains

button {
  /* Buttons should lay out like "normal" html, mostly */
  white-space: normal;  
  text-indent: 0;
}

This is a "user agent stylesheet", and the CSS spec talks about user agent stylesheets, so I don't think this is a spec violation.  But it looks like the intent of that line is to override a rule earlier in the same stylesheet, so I think it is unintentional, and easy to fix.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/style/forms.css&rev=3.146&mark=473,483#458

Dunno why Firebug was telling you something different.

Comment 2

[Boris Zbarsky [:bzbarsky]]

The <span> test doesn't apply here, since there is no constraint on the available width there.

Yeah, we migh want to rearrange the rules in forms.css to take this out... Jesse, want to write up a patch?

Comment 3

[Jesse Ruderman]

Sure.  Should I split "white-space: pre;" out of the large rule, or should I change the small rule to specify "inherit" instead of "normal"?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Specifying "inherit" seems simpler.

Comment 5

[Jesse Ruderman]

Attachment: patch

Think this patch should go in for 1.9 or after 1.9?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 302495 [details] [diff] [review]
patch

I think it's reasonable to take this for 1.9...

Comment 7

[Jesse Ruderman]

Fix (including reftest) checked in.