Last Comment Bug 543979 - Absolutely Positioned input elements next to a contenteditable element is draggable
: Absolutely Positioned input elements next to a contenteditable element is dra...
Status: RESOLVED FIXED
[fixed by bug 612128]
: testcase
Product: Core
Classification: Components
Component: Editor (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 612128
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-03 06:11 PST by Joris van der Wel
Modified: 2012-07-03 14:56 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.05 KB, text/html)
2010-02-03 06:12 PST, Joris van der Wel
no flags Details

Description Joris van der Wel 2010-02-03 06:11:27 PST
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.
Comment 1 Joris van der Wel 2010-02-03 06:12:06 PST
Created attachment 424977 [details]
testcase
Comment 2 Joris van der Wel 2010-02-03 06:13:56 PST
If someone knows of a quick workaround that would be great
Comment 3 Ria Klaassen (not reading all bugmail) 2010-02-03 07:26:50 PST
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.
Comment 4 Masayuki Nakano [:masayuki] (Mozilla Japan) 2010-02-03 10:24:57 PST
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...
Comment 5 Masayuki Nakano [:masayuki] (Mozilla Japan) 2010-02-03 10:25:41 PST
> But looks like nsHTMLEditor::IsModifiableNode() doesn't change correctly.

s/change/check
Comment 6 Ria Klaassen (not reading all bugmail) 2010-02-03 10:50:55 PST
If it was not supported it is possibly not a regression. Removing keywords per comment 4.
Comment 7 Masayuki Nakano [:masayuki] (Mozilla Japan) 2010-02-03 18:38:37 PST
http://starkravingfinkle.org/blog/2007/07/firefox-3-contenteditable/

The contenteditable is supported since Fx3. Earlier only has designMode.
Comment 8 ohmoz 2012-02-18 14:40:40 PST
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.
Comment 9 :Ehsan Akhgari 2012-04-23 19:02:58 PDT
This may be fixed by bug 612128.  If not, that's the first step in fixing this.
Comment 10 :Ehsan Akhgari 2012-05-09 07:58:34 PDT
Can you reproduce this on a Nightly build?
Comment 11 XtC4UaLL [:xtc4uall] 2012-06-30 03:36:37 PDT
This is WFM using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629030530

Note You need to log in before you can comment on or make changes to this bug.