<input>&nbsp;Text should not wrap

RESOLVED WORKSFORME

Status

()

Core
Layout: Text
--
enhancement
RESOLVED WORKSFORME
15 years ago
3 years ago

People

(Reporter: hjp, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

If, in a form, &nbsp; is used to prevent a line break between an <input> element
and the following text, and the resulting "word" extends past the right margin
of the window, the line break occurs after it, instead of before it. Thus, part
of the text is not readable without horizontal scrolling.

If CSS (<span style="white-space: nowrap;">) is used instead, the line break
occurs in the correct place (i.e., before the span, not after it).

Reproducible: Always

Steps to Reproduce:
See URL for HTML code.
Actual Results:  
See details

Expected Results:  
See details

Comment 1

15 years ago
I see that too. Also I've noticed in recent builds that &nbsp; seems to be
ignored right after (or before, I think) a form element. E.g. try this:

Page URI: <input id="url" name="url" value="http://" />&nbsp;<input
type="submit" value="Translate to English" />

Then when your resize the page it will wrap at the non-breaking space when it
shouldn't have and could have wrapped at "Page URI". Maybe this bug is related?
.
Assignee: form → font
Component: Layout: Form Controls → Layout: Fonts and Text
QA Contact: desale → ian
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Assignee: layout.fonts-and-text → nobody
QA Contact: ian → layout.fonts-and-text

Comment 4

3 years ago
Safari, Chrome, and IE all handle the testcase identically to Firefox. The input tag is not treated as a text element, and does not stick to the nbsp.

This request could be an improvement, but it's not exactly an error.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Summary: <input>&nbsp;Text is not wrapped correctly in a form → <input>&nbsp;Text should not wrap
(Reporter)

Comment 5

3 years ago
After 12 years, I don't really remember what the bug was about, but I think the subject line was misleading and the real problem was "If [...] the resulting "word" extends past the right margin
of the window, the line break occurs after it, instead of before it."

This seems to have been fixed, although not in the way I suggested (the line is now split at the &nbsp;, not before <input>). I think that's ok - it's not the best possible behaviour, but it is at least readable, and it can be "fixed" with CSS (which is a better choice than &nbsp; here anyway).

I'm closing the bug.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.