775490 - Caret goes in wrong position after leaving focus

Status: NEW

(Core :: DOM: Editor, defect, P5)

Description

[Alfons]

Attachment: FIREFOX_caret.png

User Agent: Opera/9.80 (Windows NT 5.1; U; de) Presto/2.10.289 Version/12.00

Steps to reproduce:

On a form, when leaving focus from a input type "text" during clicking onto a selectbox in the same form.


Actual results:

ONLY WITH WINDOWS XP and Firefox 13.0.1 or 14.0.1
The caret in the input text field does not disapear, but is moving about 5px down, so it is half inside the textfield borders and half outside.  


Expected results:

The focus was going to the selectbox, so there should't be a visible caret in the prior field. I never have seen a caret like this. It is half inside the borders of the input field.

Comment 1

[Loic]

Can you post the URL of the form if it's public, please.

And in addition, try in safe mode.
http://kb.mozillazine.org/Firefox_Safe_Mode

Comment 2

[Alfons]

(In reply to Loic from comment #1)
> Can you post the URL of the form if it's public, please.
> 
> And in addition, try in safe mode.
> http://kb.mozillazine.org/Firefox_Safe_Mode

It is not a public page.
But I can give you access to a test area:
http://www.cewe-freiburg.de/testbereich_C4/
USER:  loic
PASSW: bugzilla537

You can click onto "Neues Ticket",
then you are on the page where you can make tests.

Comment 3

[Alfons]

I tried it in safe mode.
No difference, the problem continues.

Comment 4

[Alfons]

Remember to test the problem with WINDOWS XP and FIREFOX 14.0.1

There is no caret problem with these combinations:
- WINDOWS 7 and FIREFOX 14.0.1
- WINDOWS XP and FIREFOX 3.6.28

Comment 5

[Loic]

Alfons, thanks for the guest account on your test server, I tried to reproduce the issue with FF14 on Win XP 32 bits, but I failed.

Each time the focus leaves a text input to a select box e.g., the caret disappears as it should be. No display glitch for the caret in the previous field.

Can you try with a new test profile, please?
https://support.mozilla.org/en-US/kb/Managing-profiles

Comment 6

[Alfons]

Attachment: Settings of FF14

Settings of FF14

Comment 7

[Alfons]

Hello Loik,
(please open the second attachement above)
Your answer brought me the idea to check my FF14 settings.
I found out, that the problem is not a XP problem, but a settings behavior.
This "hanging" caret only appears, when the setting "Markieren von Text mit der Tastatur zulassen" is checked. Additionally I found out, that the operating system is not the issue. You can test the same with WINDOWS7 or WINDOWS XP.

I have been fooled, because we had the problem here on a XP PC, 
but not on a WIN7 PC.
But the settings of FF where different on these two computers.
If you make the same settings in both computers, you can see the same result on the WIN7 PC.

I made a test on a FF3.6.28: 
There is no difference if this setting is checked or not.

Comment 8

[Loic]

Thanks for the report, it has been helpful.
In fact, with the option "Always use the cursor keys to navigate within webpages" enabled, I'm able to reproduce the issue. That's why, I asked to test with a new profile because sometimes prefs are involved. :)

I found a regression range since Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101104 Firefox/4.0b8pre anyway.

STR:

1) The website is doing UA sniffing so you need to bypass it with:
about:config > general.useragent.override = Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
2) Check the option "Always use the cursor keys to navigate within webpages"
3) Open http://www.cewe-freiburg.de/testbereich_C4/
4) Enter username (loic) and password (bugzilla537) provided in comment #2
5) Click on menu "Neues Ticket"
6) Enter something ("123" e.g.) in the input "Kunden-Nr."
7) Click on the drop-down list "Status"

Result: the caret is bad positionned at the start of the input.
Snapshot https://bugzilla.mozilla.org/attachment.cgi?id=643810

Mozregression range:

m-c
good=2010-11-04
bad=2010-11-05
Changelog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f7016571b472&tochange=5947e95a21d1

Suspected bug:
Bug 389321 - Caret invisible or at wrong place with empty contenteditable nodes

I think a reduced testcase should be searched.

Comment 9

[(no longer active)]

Aryeh, can you please take a look at this?

Comment 10

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Will do, after I get through the other bugs you asked me to look at.

Comment 11

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Reduced test-case:

data:text/html,<!doctype html><input>

No, really.  Check "Preferences → Advanced → Always use the cursor keys to navigate within pages".  Then click around to the left of the input until you succeed at putting the cursor *before* the input instead of *in* it.  The cursor will be positioned just inside the input horizontally, and its bottom will be aligned with the bottom of the input -- not the text baseline for things in the input.  This is because the cursor is not *in* the input, it's *before* it.

More generally, with this preference enabled, the cursor often ends up in weird places.  It can be in places where there's no text node.  In these cases, how are we supposed to figure out how to position the cursor?  Is this even a bug?  Where was the cursor positioned in old versions of Firefox?  I don't have an ancient enough version of Firefox lying around to test.

Comment 12

[Loic]

(In reply to :Aryeh Gregor from comment #11)
> Where was the cursor positioned in old versions of
> Firefox?  I don't have an ancient enough version of Firefox lying around to
> test.
In previous versions of Firefox before the "regression" (whatever if it's a real one or not), the caret stayed positionned at the beginning of the input field after clicking on the drop-down list with "Always use the cursor keys to navigate within pages" checked.

This past behavior seemed to be *normal* because the last position of the caret was the input field just before clicking on the drop-down list. Now, the position is a lower baseline (maybe <td> including the input).

Comment 13

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

But in older versions you could still click before the input and have it be at the same position?  So the only issue is that the cursor moves now, instead of staying where it is -- not that the position should be impossible?

Comment 14

[Loic]

Yes, the issue is not the presnece of this impossible position for the caret (in all versions, the baseline lower than the input field is clickable) but that the caret moves to this lower position after clicking on the dropdown list while its previous position was the input field.

Comment 15

[Alfons]

Why should an input field, that has been left focus, have a caret ?
The input field has been left, when clicking on the drop-down list.
Now the drop-down list has the focus.
There is no need to leave the caret lower positioned at the earlier focused field.

Comment 16

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Okay, now I understand.  The caret should just disappear in this case, I guess, or perhaps stay where it is, but not move.  I'll look and see what I can figure out.

Comment 17

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

New minimal test-case:

data:text/html,<!doctype html>
<input> 
<select></select>
<script>document.querySelector("input").focus()</script>

Clicking the <select> (with the relevant pref enabled) makes the cursor jump as we've observed.  The focus() line is necessary, interestingly.

Comment 18

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Okay -- I looked at the bug that probably caused this and don't understand the patches.  It doesn't back out cleanly (of course, being from 2010), and I also can't compile that revision for whatever reason, so I can't tell whether that bug is actually responsible.  In any event, if I'm going to tackle this I need some pointers on what to look at.  (Or maybe I should start by looking at easier bugs first to get familiar with the code around carets etc.)

Comment 19

[(no longer active)]

That bug will not be possible to back out most likely.  Here's what it did: before it we used to have hacks in nsCaret::GetGeometryForFrame (which is responsible for returning the rectangle which needs to be painted for the caret) to determine where to position the caret.  With that bug, GetGeometryForFrame is now a lot saner.  It relies on the nsIFrame::GetCaretBaseline virtual function, which is documented in nsIFrame.h.  By default it calls nsIFrame::GetBaseline, but some frames (such as block frames) require special handling.  See attachment 486272 [details] [diff] [review] for the meat of that bug.

The first thing to check here is to break in GetGeometryForFrame and make sure that the frame chosen here doesn't belong to the combobox.  I suspect that it doesn't.  Once you've verified that, I suspect that we fail to hide the caret here <http://mxr.mozilla.org/mozilla-central/source/dom/base/nsFocusManager.cpp#2077> because of the browseWithCaret value (which comes from the pref in question here) but I have no theories on what the caret is actually on.

Also, as a time saver for debugging this, F7 will toggle the caret browsing setting on and off.

Comment 20

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.