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.