Closed Bug 403426 Opened 15 years ago Closed 15 years ago

white-space:nowrap style not working for checkbox label

Categories

(Core :: Layout: Block and Inline, defect, P2)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: tschopp, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111104 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111104 Minefield/3.0b2pre

The following code doesn't render correctly in the latest nightly. The check box and the label should render on the same line.

<div style="border: 1px solid #000000;width:200px">
<input type="checkbox" id="cb1"><label for ="cb1">short label</label>
<span style="white-space:nowrap;"><input type="checkbox" id="cb2"><label for ="cb2">this is a very long label</label></span>
</div>

Reproducible: Always

Steps to Reproduce:
1. try the above-mentioned html code with a nightly build
Attached file test case
This regressed between 2007-10-19-02 and 2007-10-20-02.  Range:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-10-19+02&maxdate=2007-10-20+02&cvsroot=%2Fcvsroot

roc, I'm betting this is a regression from bug 393096.  We don't have any whitespace in there... so why are we wrapping?
Blocks: 393096
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Layout: Form Controls → Layout: Block and Inline
Ever confirmed: true
Flags: blocking1.9?
Keywords: regression
QA Contact: layout.form-controls → layout.block-and-inline
Assignee: nobody → roc
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Attached patch fix (obsolete) — Splinter Review
The bug here is basically that resetting nsLineBreaker needs to clear mBreakHere and mAfterBreakableSpace. That's simple enough

But there's a dual issue which is that when mBreakHere or mAfterBreakableSpace are set and we Reset the linebreaker, we're actually throwing away a usable line-break before the non-text-frame that caused us to Reset. The reftest in the patch shows this on lines 2 and 3. I'm fixing that by having Reset return whether a break opportunity exists at the end of the text. If it does exist, I'm recording that with a textrun flag and letting the text frame use or record the break opportunity.
Attachment #288788 - Flags: review?(smontagu)
Whiteboard: [needs review]
Version: unspecified → Trunk
Attachment #288788 - Flags: review?(smontagu) → review+
Whiteboard: [needs review] → [has review]
Whiteboard: [has review] → [needs landing]
checked in
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]
Crashed in Tp, backed out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I was about to report a bug but mine probably is the same as this, here's my example. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007113005 Minefield/3.0b2pre

<div style="width: 120px;">
     <span style="font-size: 7pt;white-space: normal">
          <span style="white-space: nowrap;">
                <input name="f1" value="1" type="checkbox">
                &nbsp;HCM-Horizon Clinicals
           </span>
          <!-- should wrap here but doesn't in ff3-->
          <span style="white-space: nowrap;"><input name="f2" value="2" checked="checked" type="checkbox">
                &nbsp;HLB-Horizon Labs
          </span>
          <!-- should wrap here but doesn't in ff3-->
          <span style="white-space: nowrap;"><input name="f3" value="0" checked="checked" type="checkbox">
                &nbsp;UNK-Undeterminable Org
          </span>
     </span>
</div>
Attached patch updated fix (obsolete) — Splinter Review
The crash was caused by
      textRun->SetFlagBits(nsTextFrameUtils::TEXT_HAS_TRAILING_BREAK);
with textRun null because we constructed just a partial textrun that was discarded, just to get state set up to process future textruns correctly. So we just need to skip this call when textRun is null.

I'll reland this shortly.
Attachment #288788 - Attachment is obsolete: true
Whiteboard: [needs landing]
Attached patch Real updated fixSplinter Review
The previous patch missed content files :-(
Attachment #291155 - Attachment is obsolete: true
Relanded
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
It's better but I don't think it's totally fixed b/c the wrapping logic is different then FF2 or IE.  It seems if there is any room, even one pixel, at the end of a "nowrap" text block then the entire next nowrap text block will be placed outside the surrounding block on the same row and only if the current nowrap text block didn't completely fit in the row will the next nowrap text block be started on the following row.  The behavior I would expect is that when the next nowrap block can not fit on the same row as the current one then it is moved to a new row.  Below is my new test code to demonstrate this.

<div style="height: 100%;width: 75px; background:red">
     <span style="font-size: 7pt;white-space: normal">
          <span style="white-space: nowrap;"><input name="f2" value="2" checked="checked" type="checkbox"/>
                &nbsp;1-aaaaaaaaaa
          </span>
          <!-- should wrap here but doesn't in ff3-->
          <span style="white-space: nowrap;"><input name="f2" value="2" checked="checked" type="checkbox"/>
                &nbsp;2-aaaaaaaaaaa
          </span>
          <!-- should wrap here but doesn't in ff3-->
          <span style="white-space: nowrap;"><input name="f2" value="2" checked="checked" type="checkbox"/>
                &nbsp;3-aaaaaaaaaaaaa
          </span>
          <!-- should wrap here but doesn't in ff3-->
          <span style="white-space: nowrap;"><input name="f2" value="2" checked="checked" type="checkbox"/>
                &nbsp;4-aaaaaaaaaaaaaa
          </span>
          <!-- should wrap here but doesn't in ff3-->
     </span>
</div>
That sounds like bug 405577. If you agree comment there, otherwise file a new bug and CC me. Thanks.
Whiteboard: [needs landing]
The patch doesn't fix the whole problem. In the test-case, it seems now that the no-wrap style applies to both checkboxes, and forces the rendering on a single line. This is not how Fx 2.0 or Opera behave (2 checkboxes on 2 different lines) which seems the correct behavior.
Resolution: FIXED → INCOMPLETE
(In reply to comment #13)
> The patch doesn't fix the whole problem.

Read comment #12 and do what it says.
Resolution: INCOMPLETE → FIXED
(In reply to comment #11)
(In reply to comment #13)

Those are definitely going to be fixed in 405577, the patch I'm going to put there fixes them.
Depends on: 407078
Depends on: 426399
Depends on: 467321
No longer depends on: 467321
You need to log in before you can comment on or make changes to this bug.