Issue 3: r19: inconsistent ENTER key behavior
Project Member Reported by mindplay...@gmail.com, Dec 17, 2007
In IE, pressing ENTER creates a paragraph - but in Firefox and Opera, it
creates a break, which, apart from the obvious layout problems, does not
carry the same semantic meaning.

It looks like you tried to correct this, but it didn't really work out. In
Firefox, sometimes you get a break immidiately - then, when you press ENTER
 after typing another line of text, these are suddenly transformed into
paragraphs. And sometimes even two of them, e.g.

  <p>content</p><p></p><p>more content</p>

I know this one's complicated to solve, but it has been done before -
FCKEditor, I believe, is one of the only editors that managed to do it
properly across most major browsers.

I believe that consistent ENTER key behavior across the major browsers
should be a high priority, as you can not produce consistent CSS layout for
content with an unpredictable structure.

I have looked into the matter myself many times in relation to other
editors, but have been unable to understand the techniques used in
FCKEditor... Maybe somebody else gets it??
Apr 7, 2008
#1 w...@sozdatel.net
I noticed some feature: in the example, you specified in the upper textfield <p>
inserted correctly in Firefox, in the bottom textfield lines are inserted through
transfers <br>.
I tried to remove the original text editing from the top textfield and got the same
bug as the bottom ...
I hope my observation will help in finalizing the interesting project.
Apr 8, 2008
Project Member #2 TJLeahy...@gmail.com
A fix for this is currently in the mootools-1.11 version.  Take a look at the
"semantics" option.  Once we get a little more testing, I think we are planning on
implementing it into the main version, thats up to cheeaun though.
Status: Started
Labels: Component-Logic
Apr 8, 2008
Project Member #3 TJLeahy...@gmail.com
(No comment was entered for this change.)
Owner: TJLeahy.Jr
Nov 5, 2008
Project Member #4 TJLeahy...@gmail.com
Closing this since I believe it was fixed when the semantics option was incorporated.
Status: Fixed
Nov 5, 2008
Project Member #5 mindplay...@gmail.com
Unfortunately, semantic fixes are still not applied when you press ENTER, so this
really doesn't affect ENTER key behavior.

In IE, it seems to work. But in Firefox, press CTRL+A (select all), backspace
(deleting entire document), then type a line, press ENTER, type another line, etc.

Semantics are not applied when you press ENTER. Turn source editing on/off to force
semantics to be applied, and from then on it works - I think, due to the fact that
Firefox creates paragraphs when a document already contains paragraphs, not because
of the semantic fixes (??)

Either way, it's still inconsistent...

Status: Started
Nov 6, 2008
Project Member #6 TJLeahy...@gmail.com
After looking through the MooEditable.Selection class, I think it would be possible
to make enter key behavior consistent, via capturing enter key events and the like. 
Cheeaun could you provide a little basic API documentation on this class (or a link
to where you got the information on ranges)?  

I think the hardest part would be making sure the cursor is in the correct position
after cleaning up the code.
Cc: cheeaun
Nov 11, 2008
Project Member #7 cheeaun
Kinda fixed. on rev 65.
Status: Fixed
Nov 11, 2008
Project Member #8 mindplay...@gmail.com
Uhm. It still doesn't work. In fact, it's worse now than it was before - try pressing 
return twice in a row.

Anyhow, nobody wants to fix this, so just let it lie - it doesn't look like any of us 
have the time or capacity to come up with a solution at this point...
Nov 11, 2008
Project Member #9 cheeaun
Hmm.. I'm not sure *which* problem you're talking about. Now, from my testing, it
have consistent ENTER key behaviour across IE, Firefox and Safari. I guess the
problem that you're talking about the code cleanup part where it removes the empty
<p></p> after you ENTER twice?
Nov 12, 2008
#10 isolatio...@gmail.com
hey cheeaun, 

I encountered similar problems to what you describe with the code cleanup and another
one relating to linebreaks. There were basically two things that I noticed:

First, the code cleanup is *too* aggressive; it blindly converts every linebreak to a
paragraph tag, even when you have mixed paragraphs and linebreaks (e.g. shift-Enter).

Second, and probably what mindplay.dk  is referring to, is that the editor becomes
confused when paragraphise is enabled and you enter linebreaks. If you enter a
linebreak (shift+Enter) it appears properly, however if you then add a normal
paragraph break (just Enter) it affects the linebreak of the line above it, too. You
can enter multiple sequential line breaks and they will "stick", however the next
paragraph break you create will convert the most recent linebreak to a paragraph break.

Thank you for your continuing work on this editor, Cheeaun.
Nov 12, 2008
Project Member #11 TJLeahy...@gmail.com
Shift+Enter should now work in r67. It's doesn't behave 100% the same cross browser,
but it does work in Firefox, IE, Opera.  Don't have safari installed, but for
whatever reason I couldn't get Chrome to work properly.  From my testing, here's what
I found.
Firefox: Have to hit the down-arrow key after a shift+enter to get the cursor onto
the next line.  Also, hitting enter on a line after a break will cause that line to
be placed in a paragrph of its own (I believe this is a problem with
MooEditable.enterListener).

IE: Works as expected.
Opera: Works as expected.
Chrome: Doesn't work at all.
Safari: Untested.
Status: Started
Nov 12, 2008
Project Member #12 cheeaun
I don't think there's a problem with Shift+Enter in non-IE browsers though.
'insertBreak' function for those browsers are kinda unnecessary?

And the only problem I know is, ya, the enterListener function which needs to be revised.
Nov 13, 2008
Project Member #13 TJLeahy...@gmail.com
The reason I implemented it for all browsers is because the semantics option tries to
remove all those erroneous <br>s, so I add the class mooeditable-skip to the <br>. 
It's not the ideal solution, but the semantics regular expressions don't recognize
it, so it leaves them alone.  If you can come up with a better solution, definitely
put it in; that's just the best I could whip up relatively quick here at work ;).
Nov 13, 2008
Project Member #14 TJLeahy...@gmail.com
After a little testing, it seems to work fine if you only enable it in IE.  r68 makes
shift+enter consistent cross-browser, again untested in Safari.  The only bug left in
this ticket appears to be hitting enter after a few shift+enters in Firefox, which
causes the last line to be "paragraphised".
Nov 14, 2008
Project Member #15 mindplay...@gmail.com
I just made a discovery that could be useful.

As you know, Firefox will default to paragraphs automatically, if you press ENTER
while you're already in a paragraph.

My biggest problem has been that when you start with an empty document, this doesn't
happen.

Well, try editing source, then insert the following:

<p>&nbsp;</p>

Then switch back to WYSIWYG, start typing, press ENTER. It works.

I tried this in a couple of different lightweight WYSIWYG editors - it works
consistently in Firefox.

Note that <p></p> will not work. You need the &nbsp; to preserve the paragraph.

Odd...

Now if we could somehow detect if the document is empty, e.g. after CTRL+A, DEL or
BACKSPACE ... and then insert the default empty paragraph with a nbsp...

??
Dec 3, 2008
#16 nickolas...@gmail.com
Currently (r71) if I open the demo
http://mooeditable.googlecode.com/svn/trunk/examples/default-additional-buttons.html
and then;
 - click the text area
 - make "this is cool" an H1 via the button
 - press enter

In Firefox (3.0.4) it turns it into a normal paragraph

In Chrome (0.4.154.29) and Safari (3.1.2 win) it create two more blank h1 tags!

In IE7 it works.


Jan 9, 2009
Project Member #17 TJLeahy...@gmail.com
@mindplay.dk

Does the <p>&nbsp;</p> trick work cross-browser, or is that a Firefox only fix?
Jan 9, 2009
#18 rasmus.m...@gmail.com
I tested only with IE7 and Firefox, those worked.