1234777 - caret browsing: caret is half a line too low

Status: NEW

(Core :: Layout, defect)

Description

[Rainer Bielefeld]

Attachment: Screenshot

Since 2.39(?) from time to time at arbitrary places on page I see the caret appearing at or moving to a position ½ line hight below the place where it should be.

Steps how to reproduce with  SeaMonkey German 2.39 final Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0 from official download area)  Gecko/20100101  Firefox/42.0  Build 20151103191810  (Classic Theme) on German WIN7 64bit:

1. In browser open <http://www.reichelt.de/>
2. Into search string input line on page type "xxx" → <Enter>
   » Caret moves to most left position in input line,  ½ line hight too 
     far to the bottom of the page

Additional information
----------------------
a) also reproducible for me in safe mode
b) Might be related to text cursor browsing
c) Seems not to cause any problems

Comment 1

[Rainer Bielefeld]

b): definitively "Caret Browsing" problem, you will have to switch it ON before
    you do step 1
c) 46.0a1 (2015-12-22) also affected, so Core problem (or similar)

Comment 2

[Tony Mechelynck [:tonymec]]

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0" (en-US) ID:20151223030323 CSet:35b211eaad1fa828064514c547057e4400e24459

With caret browsing on (F7) I can see the problem, but barely. After searching as described in comment #0, the "caret" bar is properly positioned within the input box; however, if I repeatedly tab through the page, I notice that the caret sometimes positions itself a few pixels lower than it ought to. How much varies from one control to the next, with no logic or system that I can see. On some image links the caret occupies only the bottom half of the image's height but does not overflow the bottom.

Not sure if this bug belongs in some Layout component, in Toolkit: XUL Widgets, or somewhere else again.

Comment 3

[Tony Mechelynck [:tonymec]]

Attachment: An extreme case, with Firefox 46.0a1

Here is an extreme case which I noticed after typing the preceding comment. The currently selected link (an image link) is outlined in dotted black, and the browsing caret is the extremely small black line, just a few pixels high at bottom left inside that dotted sqare.

Comment 4

[Rainer Bielefeld]

Effekt on <reichelt.de> already  REPRODUCIBLE with  DE  SeaMonkey 2.5  (Windows NT 6.1; WOW64; rv:8.0.1)  Gecko/20111121  Firefox/8.0.1   Build 20111121045514  (Classic Theme) on German WIN7 64bit

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

It sounds like you're aware of a regression range here -- could you state that regression range in terms of Gecko versions (which Firefox versioning matches) rather than SeaMonkey versions?

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Sorry, I guess comment 4 is saying that the bug has been around for years.

Comment 7

[Tony Mechelynck [:tonymec]]

Rainer: If it affects the trunk, we set the Version to Trunk. Tracking flags are used to mention in which older branches it was noticed. For missing tracking flags (such as those for branches no more updated, or anything about SeaMonkey in a mozilla-central product) I use the QA Whiteboard if available, otherwise the plain Whiteboard.

Comment 8

[Tony Mechelynck [:tonymec]]

David: Yes indeed. It happened in Firefox 8 (which of course won't be fixed by now) and it still happens in Firefox 46. SeaMonkey 2.39 is equivalent to Firefox 42.

Comment 9

[Tony Mechelynck [:tonymec]]

After testing this bug, I've left accessibility.browsewithcaret on, and I see the problem happen even on bugzilla.mozilla.org pages (which I browse a lot), but so far only on widgets, not on plain links or input fields. For instance when I hit the Tab key once while typing this comment, focus goes to the [Save Changes] button below it, and there the top of the caret is a pixel or two left of the bottom-left end of the curve for the letter S, and its bottom end is a few pixels outside the button. Then tabbing again brings the caret on the checkbox for "Need information from", which is (perhaps intentionally) about 1em down relative to the label (about centered between the label and the input box for the address); there the caret starts at the bottom of the top-left "border-radius" rounding for the checkbox (3px or so lower than the top edge) and ends about the same distance lower than the bottom horizontal border of the same checkbox. Tab again: the rolldown comes into focus, but no visible caret. Tab again: the input box comes into focus, with its insertion point correctly displayed. And so on…

AFAIK the present bug is only about a cosmetic problem, but it is esthetically disturbing.