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.

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?

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.)

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.

This appears also in empty contentediable elements.

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

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

(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.

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?

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.

Sounds like Ehsan is dealing with this in bug 389321.

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

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.

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

Related bug: 885406