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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted, testcase
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.
Keywords: regression, regressionwindow-wanted
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.
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
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 612128]
You need to log in before you can comment on or make changes to this bug.