If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Erroneous backspace behavior - backspace stops working

RESOLVED WORKSFORME

Status

()

Core
Editor
--
major
RESOLVED WORKSFORME
12 years ago
10 years ago

People

(Reporter: Danny Bloemendaal, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Now that we (finally) have #92686 fixed, a few nasty things are happening. When you press enter twice when you are in a paragraph and then, when you try to remove those new lines, the caret is stuck and backspace is not working (gets in some kind of a loop it can't get out)

Reproducible: Always

Steps to Reproduce:
1. In wysiwyg mode, make sure the buffer contains this: <p>test</p>
2. Then put the cursor behind the word 'test'.
3. Press the return key twice (or 3x).
4. Hit backspace to undo this. You will see it gets stuck.




I have tried this with 1.5b2 and 1.0.7 both on MacOSX and WindowsXP.

I'm not sure if this is related but the code that gets produced when pressing these returns is will not win the beauty contest. Many times I end up with a big mess of <br />s, sometimes even without any paragraph around them.

Also, in my example (<p>test</p>), place the cursor after the 'e' and then press return followed by backspace. As you can see, something weird happens too. It should undo the retun but instead it removes the paragraph and leaves the break (<p>te<br />st</p>)

To sum up: someone has to take a good look at this break/paragraph behavior because at this point it is erratic und sometimes unpredictable. To me, unfortunately, this is a showstopper to use Mozilla/FF for CMS editing.

Comment 1

12 years ago
I can confirm that I get the same behaviour with Kupu, but further investigation seems to indicate that the problem comes from Kupu's attempts to tidy up the weird html produced by Mozilla (specifically the mix of <br> tags inside and not inside <p> tags.

Comment 2

12 years ago
There does appear to be a genuine Mozilla bug here though. In an editor frame hitting enter on a paragraph containing a single <br> inserts a spurious extra <br> tag.

e.g. If you have the cursor in a paragraph <p><br/></p>, hitting enter gives you <br/><p><br/></p><p><br/></p>
(Visit http://www.dynarch.com/demos/htmlarea/examples/core.html for a suitable editor window)
QA Contact: editor
Assignee: mozeditor → nobody
Duncan, do you still see this with a current version and if so list a full set of steps to reproduce?

Note: Reporter's (Danny's) email address is dead

Comment 4

10 years ago
Does not reproduce in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111404 Minefield/3.0b2pre

Check http://www.mister-pixel.com/ever/bugs/firefox/313582.html

However, it seems that there are still problems: put the cursor at the end of the paragraph and hit ENTER twice; this will create an additional BR;

Not to mention what happens if you paste using the keyboard or contextual menu: CRASH.

I'll report a separate bug for this issue, seems to be caused by designMode="on" or contentEditable="true" (either of those crashes the browser on paste).
so => WFM
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.