Open
Bug 92231
Opened 23 years ago
Updated 2 years ago
problems formatting text that flows to next line
Categories
(Core :: DOM: Editor, defect, P3)
Core
DOM: Editor
Tracking
()
NEW
Future
People
(Reporter: bruppel1, Unassigned)
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+) Gecko/20010724 BuildID: 2001072403 This is pretty hard to explain, but it's annoying and not knowing the workaround could frustrate users. This problem is with lines of text that are automatically wrapped down to the next line in mozilla's text boxes (such as the Description text box I'm using to enter this description in bugzilla). This happens when one types or pastes long lines from another app (like notepad). If I go to the beginning of one of these lines that was wrapped down from the previous line and hit the space bar to indent the text, nothing happens. The workaround is to hit enter to break the flow, but this isn't very intuitve and I'm not sure that it's the correct behavior. It looks like the textbox is trying to be smart by not letting the spaces mess with its linebreaks, but perhaps a "stupid" textbox would be better. Reproducible: Always Steps to Reproduce: 1.find a multiline textbox (such as those in http://www.mozilla.org/quality/help/bugzilla-helper.html ) 2.type in a long sentence and let your typing automatcially wrap to the next line. 3.move your cursor to the beginning of that next line 4.hit space Actual Results: nothing happens Expected Results: the text would move forward because you entered a space in front of it.
Comment 1•23 years ago
|
||
Does this actually work the way you want in any other browser? Mozilla used to have the "dumb" text box that you propose and bugs were getting filed on it all the time (bug 19265 and all its duplicates).
Reporter | ||
Comment 2•23 years ago
|
||
It works the way I want in NS4.x. IE6 does some crazy stuff with putting the spaces on the previous line. The way it works now, Mozilla just ignores the inserted spaces. I looked at 19265 . I wouldn't ask for a "dumb" text box anymore, but I think it's just a matter of the textbox counting spaces inserted on the next line as part of the next word, and not the end of the previous word. Should I send this bug over their way or something?
Comment 3•23 years ago
|
||
Over to editor
Assignee: trudelle → beppe
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets → Editor
Ever confirmed: true
QA Contact: aegis → sujay
Comment 4•23 years ago
|
||
talked with Kin and reviewed the issue, off to layout
Assignee: beppe → attinasi
Reporter | ||
Comment 5•23 years ago
|
||
Thanks for looking into this :)
Comment 6•23 years ago
|
||
I know this problem well. It is a little worse than described because, if I type a bunch of spaces at the beginning of a wrapped line, they do not show up, but when I go to the line above and add more text so that the line wrap changes, the spaces then show up in the middle of the next line. I guess the problem is that we are collapsing the spaces when they are at the beginning of the line, but not when they are preceeded by some characters. I'll accept this though I do not see yet how it is a layout problem (I'm admitedly not too familiar with the edit control), but I cannot give it much priority at this time. Also CC'ing rods since he is into form controls in a big way.
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Priority: -- → P4
Hardware: PC → All
Comment 7•23 years ago
|
||
I've been encountering a similar problem for as long as I've been using Mozilla, which is now nearly a year. The problem I'm encountering seems to manifest in any text area throughout Mozilla. It's most noticable for me in mail composition, but also in text areas in forms (like the one I'm typing into right now). The problem is that occasionally, when I hit the enter (carriage return) key, the cursor moves down two lines rather than one. Hitting delete moved me back one line, but then another immediate Enter will drop me down another two lines. This is hard to reproduce, but it happens to me very often. It's most noticable in the following situations: o replying to an RTF mail message sent by Microsoft Outlook o replying to a text message when I hit the enter key after the text has wrapped at least once on its own o when I edit text that I have cut or copied from another Windows text editor and then pasted into a Mozilla text area I should mention that I compose mail in text-only mode. No RTF formatting, no HTML formatting. I assume that I'm using the same text widget for composing mail as most people use to edit text in form text areas. I'll also be so bold as to provide my theory as to why this is happening: I think Mozilla is not throuroughly assuring a consistant line-ending convention for pasted text, entered text, and mail text. My guess is that internally, Mozilla works with single-character line endings, but doesn't always remove one of the <cr><lf> pairs from Windows text. Remember that Windows ends lines with <cr><lf>. Mac OS ends lines with <cr>, and Linux, <lf>. (At this point, I pressed Enter and had my cursor drop two lines instead of one!) So to support Mac OS, you simply have to replace <cr>s with <lf>s, but for Windows, <cr>s, if they preceed a <lf>, need to be deleted. If Windows <cr>s get replaced with <lf>s, then the text ends up containing <lf><lf>: two returns! Anyway, that's my problem and my theory. Hope it helps.
Comment 8•23 years ago
|
||
This seems related to bug 88024 and may even be partially fixed by that fix... Would people retest with current (Oct 10 2001 or later) builds?
Reporter | ||
Comment 9•23 years ago
|
||
Using October 11 builds, this problem is still there.
Updated•23 years ago
|
Target Milestone: --- → mozilla1.0.1
Comment 10•23 years ago
|
||
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1 I will be pulling bugs from 'future' milestones when scheduling later work.
Priority: P4 → P1
Target Milestone: mozilla1.0.1 → Future
Updated•17 years ago
|
QA Contact: sujay → editor
Updated•17 years ago
|
Assignee: attinasi → nobody
Status: ASSIGNED → NEW
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•