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.
Steps to Reproduce:
1. Open the attached test case
2. Right click or press enter in the input field at the bottom
The input element gains resize and drag buttons and can be used to change the position and size of the input element.
The input should NOT receive any resize or drag buttons and should not be draggable or resizable.
Created attachment 424977 [details]
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.
If it was not supported it is possibly not a regression. Removing keywords per comment 4.
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;">
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