User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 Absolutely Positioned input elements next to, but not inside a contenteditable element is draggable and resizable. Reproducible: Always Steps to Reproduce: 1. Open the attached test case 2. Right click or press enter in the input field at the bottom Actual Results: The input element gains resize and drag buttons and can be used to change the position and size of the input element. Expected Results: The input should NOT receive any resize or drag buttons and should not be draggable or resizable.

If someone knows of a quick workaround that would be great

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20100202 Minefield/3.7a1pre I see the intended behaviour with Firefox 2.0 but not with Firefox 3.0 and later. A regression range will prove if the problem goes indeed that far back.

Looks like the enter key press event is listened by the HTML editor after the input editor ignored the event. There are two ideas: 1. HTML editor should remove the listener when its editable nodes lost focus 2. HTML editor should check whether the editor is editable or not *by* the HTML editor. I think the first is better, but looks like we are using 2nd way. But looks like nsHTMLEditor::IsModifiableNode() doesn't change correctly. I wonder why this is a regression. Such bug should be there since beginning of contenteditable support...

> But looks like nsHTMLEditor::IsModifiableNode() doesn't change correctly. s/change/check

If it was not supported it is possibly not a regression. Removing keywords per comment 4.

http://starkravingfinkle.org/blog/2007/07/firefox-3-contenteditable/ The contenteditable is supported since Fx3. Earlier only has designMode.

The bare minimum necessary to reproduce this bug is the following: <input type="text" style="position:absolute;"> <div contenteditable="true">test</div> Firefox does not appear to care where these two elements are in relation to each other. I have tried burying one, the other, or both in a bunch of nested divs, and the abspos input stays editable.

This may be fixed by bug 612128. If not, that's the first step in fixing this.

Can you reproduce this on a Nightly build?

This is WFM using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629030530