Absolutely Positioned input elements next to a contenteditable element is draggable

RESOLVED FIXED

Status

()

Core
Editor
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: Joris van der Wel, Unassigned)

Tracking

({testcase})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by bug 612128])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 1

7 years ago
Created attachment 424977 [details]
testcase
(Reporter)

Comment 2

7 years ago
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.

Comment 8

5 years ago
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.
Depends on: 612128
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: 5 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.