542116 - Cursor/caret inside empty input text/password or contenteditable element ignores font-size

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Emil Ivanov]

When there is empty input type file or password the cursor is with height of the content instead with the font-size. If there is any letter the cursor is with the correct font-size.

This is regression in 3.6 and trunk.

Comment 1

[Emil Ivanov]

Attachment: testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

Looks like the behavior changed between 2009-05-18 (rev 9703fd69e126) and 2009-05-19 (rev 409416c625bc).  Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9703fd69e126&tochange=409416c625bc

Looks like a change from bug 481751.  Karl, was this an intentional change, or did we just change the block height and caret happens to use the block height if there's nothing on the line?

Comment 3

[Karl Tomlinson (:karlt)]

It wasn't an intentional change.  ISTR there being no text frame when there is no text and so the caret using the block height sounds likely.
(BTW, the cursor also changes height when adding characters from fonts with larger heights, which is not this bug nor a regression, but kinda related.)

Comment 4

[Emil Ivanov]

I mean input type text not file, correcting the summary. There is no way to change the field height of input type file. The testcase is correct.

Comment 5

[Emil Ivanov]

This appears also in empty contentediable elements.

Comment 6

[Emil Ivanov]

Attachment: testcase2

Comment 7

[bmccann]

Would we be able to mark this as a 3.7 blocker?

Comment 8

[bmccann]

This is one of a few contentEditable bugs that has made it difficult/impossible to implement Google Spreadsheet's formula highlighting in Firefox.  We'd like to turn the feature on in FF 3.7 assuming enough of the issues have been addressed in the browser.  Thanks!
http://googledocs.blogspot.com/2010/05/formula-highlighting-in-spreadsheets.html

Comment 9

[Karl Tomlinson (:karlt)]

(In reply to comment #5)
> This appears also in empty contentediable elements.

The contenteditable behavior is not a regression from bug 481751
(contenteditable behaved like that in Firefox 3.5.), but it is quite likely that a fix would correct both input and contenteditable elements.

Comment 10

[Karl Tomlinson (:karlt)]

Transferring Ben's blocking request to 3.7.

Ben, can you clarify please whether it is the input or contenteditable that is involved in Google Spreadsheet's formula highlighting, and why the height of the cursor makes this difficult/impossible?

Comment 11

[bmccann]

We use the contentEditable to do the formula highlighting since you can't have multiple colors in a standard input.  The cursor generally behaves strangely in Firefox's contentEditable such as being in the wrong position, being invisible, or being the wrong size.  To deal with this, the feature had to be disabled in Firefox and we fallback to the regular input.

Comment 12

[Karl Tomlinson (:karlt)]

Sounds like Ehsan is dealing with this in bug 389321.

Comment 13

[(no longer active)]

I've confirmed that bug 389321 will fix this.  I'll attach a reftest as well.

Comment 14

[(no longer active)]

Attachment: Reftests

Comment 15

[(no longer active)]

Attachment: Part 2: another assertion annotation

These reftests will also cause an instance of the assertion in bug 596901 in layout/reftests/editor/passwd-4.html, since that test focuses a password field, which leads to a call to BeginSecureKeyboardInput, and since the internal flag has already been corrupted, we assert in that test as well.

The good news is that this assertion annotation is temporary, and can be removed once bug 556873 is resolved.

Comment 16

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/764912922f20
http://hg.mozilla.org/mozilla-central/rev/a85c59d4a26e

Comment 17

[Jonah Bron]

Related bug: 885406