100801 - label {display:block} causes severe layout problems

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jason Johnston]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4+)
Gecko/20010919
BuildID:    2001091903

Setting display:block on a <label> element causes severe layout problems:

1) When inside a table cell, the cell grows extremely wide and the label disappears.
2) When not inside a table cell, all surrounding content is not displayed.

This has been occurring since the fix for bug 47149. It is related to bug 96813
(which I can't reproduce).

This is causing big problems with pages that used display:block on <label>
elements as a workaround for bug 47149. As a stopgap measure, "label
{display:inline !important}" should be added to html.css to prevent the display
property from being set, until the label element is properly fixed.

Testcases are attached below.

Comment 1

[Jason Johnston]

Attachment: label element bug in table cell

Comment 2

[Jason Johnston]

Attachment: label element bug not in table cell - content should appear but doesn't.

Comment 3

[Jason Johnston]

As I am not currently set up to create patches, could someone please do me a
huge favor and create a patch to add the following:

label {
  /* our <label> support is badly broken. (b=100801) */
  display: inline !important;
}

to forms.css under "miscellaneous form elements".

Adding this declaration fixes both testcases as well as all pages I had noticed
as broken. It's a stopgap measure and won't be sufficient to fix our <label>
support, but it will make the effects less extreme.

Comment 4

[Marc Attinasi]

Attachment: patch: force label elements to be inlines

Comment 5

[Marc Attinasi]

Comment on attachment 51570 [details] [diff] [review]
patch: force label elements to be inlines

(typo in desc.)
sr=attinasi

Comment 6

[Marc Attinasi]

reassign to rods - Rod, please review the patch and, if acceptable, check in to
trunk. Jason did all the work, I just created the patch and sr'd it.

Comment 7

[rods (gone)]

seems reasonable r=rods

Comment 8

[Jason Johnston]

Thanks very much Marc and Rod for getting the patch made and reviewed, I greatly
appreciate it. What needs to be done from here to get it checked in on the trunk?

Also, since this bug was present in the 0.9.4 branch, what are the chances of
getting this in on the Netscape commercial branch as well? From my standpoint
this looks like a low-risk/high-gain checkin, but it's obviously not my place to
decide that.

Comment 9

[Jason Johnston]

The workaround patch for this bug has r= and sr= but has not been checked in ...
can somebody get this pushed through please?

Comment 10

[Marc Attinasi]

I just ping'd Rod - hopefully he will check this in very soon...

Comment 11

[PTRourke]

I'm seeing this problem with XML elements (i.e., not HTML) as well; have filed a
separate bug 107417  .  

Comment 12

[Boris Zbarsky [:bzbarsky]]

*** Bug 107763 has been marked as a duplicate of this bug. ***

Comment 13

[Boris Zbarsky [:bzbarsky]]

NOte that that patch (which _was_ checked in) makes it difficult to change label
displays to "none" in js (you have to remember to add !important, which means
you can't use the shortcut methods in the DOM and have to use setPropertyValue).

Comment 14

[rods (gone)]

fixed

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 136006 has been marked as a duplicate of this bug. ***