539143 - Cursor appears outside/above input box

Status: RESOLVED DUPLICATE of bug 389321

(Core :: DOM: Editor, defect)

Description

[bmccann]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7

The cursor appears outside/above the input box until you start typing.

Reproducible: Always

Steps to Reproduce:
1. Open the attached file.
2. Click in the input box.

Comment 1

[bmccann]

Attachment: Tiny file which shows that FireFox cursor is broken

Comment 2

[Ria Klaassen (not reading all bugmail)]

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2pre) Gecko/20100106 Namoroka/3.6pre

No cursor in the box but you can still type in it.
The really bad news is with Minefield, not only no cursor, but it is also impossible to type.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I have no problems typing in the minimal testcase with today's Minefield build on Mac.

That said, it sounds like two separate editors are not being happy here.  Peter, any idea what's up and how we can fix it?  Should text inputs in a contenteditable setup not init their own editor?

Comment 4

[bmccann]

It sometimes is impossible to type in the contentEditable in FireFox:
https://bugzilla.mozilla.org/show_bug.cgi?id=539323

Comment 5

[bmccann]

Would we be able to mark this as a blocker for 3.6 or at least 3.7?  It makes contentEditable unusable, so I think it should be a high priority.

Comment 6

[Boris Zbarsky [:bzbarsky]]

It's certainly not a blocker for 3.6 unless it's a regression from 3.5.  Is it?

For 3.7, we'll see.

It hardly makes contentEditable "unusable"... it just means that using it on a subtree containing a text input leads to odd behavior when clicking on the text input.

Comment 7

[bmccann]

Thanks.
No, it's not a regression.  It's broken in 3.5 as well.
(As a web developer I'd say it's unusable.  Between this bug and 539323 there's no way I can release anything that relies on a contentEditable.  I'm developing a feature which relies on contentEditable to do rich text and I'm planning to release for Chrome only because of these bugs.)

Comment 8

[(no longer active)]

(In reply to comment #3)
> I have no problems typing in the minimal testcase with today's Minefield build
> on Mac.

I don't get a cursor, and I can't even type.  The only way that I've managed to type into the input box is by tabbing to it.  Once I start to type, the caret shows up fine, though.

> That said, it sounds like two separate editors are not being happy here. 
> Peter, any idea what's up and how we can fix it?  Should text inputs in a
> contenteditable setup not init their own editor?

Which two editors are you talking about?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Which two editors are you talking about?

The one for the anonymous div in the text control and the one for the contenteditable root.

Comment 10

[(no longer active)]

(In reply to comment #9)
> > Which two editors are you talking about?
> 
> The one for the anonymous div in the text control and the one for the
> contenteditable root.

I'm only seeing one contenteditable node in the testcase.  There is not text control.  Am I missing something?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Er, nevermind.  For some reason I thought there was a text input there.  Maybe because it got moved to form controls... or because of the summary.

In which case, sounds like a pure editor/caret issue.

Comment 12

[Peter Van der Beken [:peterv]]

Pretty sure this used to work ok at some point, does it work in 3.0? If so, anyone have a regression range?

Comment 13

[Peter Van der Beken [:peterv]]

Actually, this looks like a dupe of bug 389321. Seem the problem is with divs but not with spans or something.