line breaks don't work properly

[marcvangend]

When I try to enter a line break <br /> by pressing shift-enter, the cursor moves a little to the right. There is no new line created.

When I enter a space after that, the new line is created, containing the space. Pressing backspace remove the space and the new line.

Next, when I press shift-enter again, the new line comes back immediately. However the padding between the current paragraph and the next paragraph disappears.

(tested in IE 6.0.2800)

[jf.hovinne]

Confirmed - tricky IE designMode issue. Needs more review.

[dor]

It seems that the bug occurs in every element that has a CSS background declaration, of any kind. Which means that even the following background declaration:

elem { background:none; }

triggers the bug in IE6.

If the background declaration is removed from an element, the bug wouldn't be triggered.

If you make IE6 to treat the element is if it "hasLayout" (via CSS), then the bug wouldn't be triggered despite any background declaration.

I tried to find a solution but couldn't find.

[dor]

Replying to dor:

If you make IE6 to treat the element is if it "hasLayout"

instead: "element is if it" it should be: "element as if it"

sorry I can't edit...

[donrl]

Dor's comment about CSS backgrounds is true in IE7 and IE8 as well.

[mr_lundis]

I've been looking into this issue. I tried giving the elements layout, but this causes nasty resize-handles to show, at least in IE 8.

This is really a hard issue to solve - considering to leave things as-is for now...

[mr_lundis]

Okay, I think I might have found a solution (finally!); the oncontrolselect event. Preventing the default action should stop the handles from showing when the element has layout. This also means that it won't be necessary to run the iframe in compatibility mode in IE8.

I haven't tested it yet though.

http://msdn.microsoft.com/en-us/library/ms537844(VS.85).aspx

[mr_lundis]

Preventing the default action on the oncontrolselect event does indeed stop the controls from showing, but it also prevents editing the element.

This is not a blocking issue, and there will be no fix for this in 0.5 I'm afraid. If someone comes up with a fix it'll be included in a future maintenance release.