Closed Bug 189700 Opened 22 years ago Closed 22 years ago

Space not shown/cursor doesn't move if typed at the end of a line where last caracter touches the edge of the boxe

Categories

(Core :: DOM: Editor, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 143950

People

(Reporter: jubijub, Assigned: mozeditor)

Details

(Whiteboard: DUPEME)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030119 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030119 when I type my message : each type the last caracter I've typed touches the righ edge of the boxe, if I hit space, the space is not shown, and the next word begins as if there were no space beteen (ie touches the left edge of the box)...(eventhough space is perfectly taken into account, because it appears once the message is posted) Reproducible: Always Steps to Reproduce: 1.Find a page with a form to fill (like this one, or a forum form, or whatever) 2.Type a full line of caracter, and stop when the last caracter touches the right edge of the box (ie if you type another caracter, you'll start a new line) 3.now hit space Actual Results: The cursor won't move : if you type a new word, it'll start on a new line, on the left edge of the box, as if there were no space between this world. Moreover, if you clic back at the end of the previous word and hit space, the new line won't move Expected Results: The space should be shown, the cursor should go on the new line and show the amount of empty space ====>This is just cosmetic, because the spaces are taken into account when posting, but it's very annoying on a forum if you try to make a special ASCII layout P4 mobile computer with emmebed keyboard, and explorer 3 USB mouse
According to http://bugzilla.mozilla.org/show_bug.cgi?id=180665#c7 I believe this is invalid.
What do you mean by this ? Have you tried to reproduce the behaviour ? It still does it for me, in any editbox I can find on any given webpage.
As the linked to comment says, "that is by design. The alternative is for the space to show up leading the next line, and people really hate that." Thus, this behaviour being by design, this is no bug and thus invalid. Alternatively you could request for the behaviour to change to showing the whitespace, which would probably be marked WONTFIX (unless you can present convincing arguments for _why_ that behaviour would be better than what we currently do; and I don't think wanting to do a special ASCII layout fits that bill).
Whoa...I'm speechless : what an open minded spirit down here :/ Shall I remind you that an interface is suppose to react to show that the user's entry has been taken into account : in this case, when you hit space, nothing happens, that is to say the interface fails to demonstrate that the action has been processed, since no space appears. (eventhough it's perfectly shown when the box is validated, so it's just cosmetic). I really see no objective reason why a requested ASCII space shouldn't appear only because some people find it ugly...I think the basic stuff you can ask from a software is to do what you ask him...I find it strange...so now, when using OpenOffice, I want that when I choose Black color to write text, the soft puts red instead, because I find black very sad, and red is more pretty... :) I though that Mozilla was a customizable software...what is nice with customization is that you can choose it or not...in this case, someone else has chosen not to display this caracter (which is a non-standart behaviour)...I'm not pleased with this : I can understand that some people don't want it, but at least, the choice could be left to the final user...otherwise it's not customization, it's imperialism :D BTW, I would like to have arguments why people hate have a ASCII space at the beginning of a line...when you press start, you expect to see an ASCII space...that's the very basic function of the SPACE key. I really would like to hear you answer on this
Confirming ->form controls
Assignee: form-submission → form
Status: UNCONFIRMED → NEW
Component: Form Submission → Layout: Form Controls
Ever confirmed: true
QA Contact: vladimire → tpreston
1) This is editor. 2) This is invalid. 3) This is a dup.
Assignee: form → jfrancis
Component: Layout: Form Controls → Editor: Core
QA Contact: tpreston → sujay
Whiteboard: DUPEME
Why is this invalid?
*** This bug has been marked as a duplicate of 143950 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
v dupe
Status: RESOLVED → VERIFIED
right...sorry for this one then...
so nothing will change ???
correct. if you try other popular browsers, i think you will see the same behavior (try text areas like the one's in bugzilla for browsers that don't have mail compose or html editors).
that ain't fair : you could at least leave the choice... on the topic of which link is given a bit above, people are unhappy with this as well... I think both reason are understandable and have pros and cons, so the choice should belong to final user... Basically, a tickbox with : wrap last space caracter with last word at the end of line would be nice : those who like it tick it, those who don't don't tick it...easy, and fix the problem for everyone (given it has been reported in different ways at least 3 times with each time other people saying they agree with the bug reporter, it means there are quite a lot of people that would like to have the choice. Moreover, I think it's quite sad that instead of trying to please everyone trough a customization feature, you just say : if you don't like it try another one : you know perfectly the other one is IE, and it suxx
You need to log in before you can comment on or make changes to this bug.