Closed Bug 420987 Opened 13 years ago Closed 13 years ago

Textarea caret invisible at certain zoom levels on Windows


(Core :: DOM: Editor, defect)

Not set





(Reporter: cpearce, Assigned: roc)


(Keywords: access)


(2 files, 2 obsolete files)

The textarea's caret is invisible at one zoom out with specific body margin and padding. This only happens on Windows, and only happens with specific margin and padding values on the body tag. I discovered this because it happens with bugzilla's comment textarea, i.e. on Windows at zoom-out level one the caret is not visible in bugzilla's comment field.

This bug exists at least as far back as FF3b3, only on Windows.

1. Load testcase.
2. Zoom out page by 1 (CTRL+MouseDown).
3. Focus textarea, note that no caret appears.
4. Type something, you'll see your typed text appear in the textarea, but still there's no caret.
Requesting triage... Roc?
Flags: blocking1.9?
I've seen missing caret when zoomed out on Linux.
Should be an easy fix, just change the caret drawing code a bit to manually span the caret rect to pixels before drawing directly to gfxContext, and refuse to make it disappear altogether.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
No longer blocks: contenteditable
Same happens with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008041004 Minefield/3.0pre ID:2008041004

The caret is invisible on OS X when the textarea doesn't contain any text. Further it happens only for each second decrease/increase.
OS: Windows Vista → All
Version: unspecified → Trunk
Screen reader usage breaks for current generation Windows screen readers when this happens -- the user cannot read the text in the text area. Newer screen readers are moving to an engineered interface for the caret pos and don't have the problem.
This is too annoying to ship with. If the code needs to be changed a lot I would appreciate if someone else takes it from here.

Anyway, this basically does what Roc said in comment 3 and fixes the problem for me.
Assignee: nobody → aaronleventhal
Attachment #315203 - Flags: superreview?(roc)
Attachment #315203 - Flags: review?(roc)
This is the right idea but nsDisplayCaret needs to be changed so that its bounds reflect the increased width of the caret. I think the correct thing to do would be to change the width of mCaretRect itself so that it's a minimum of one device pixel wide.
I don't have time to twiddle with this patch, I'll let someone more familiar with the area do the rest from here.
Assignee: aaronleventhal → nobody
Assignee: nobody → roc
Ah, we actually do set the caret width to be one device pixel right now. We just don't update it dynamically when zoom changes.
Attached patch fix (obsolete) — Splinter Review
I think this is the way to go. nsCaret needs to cache less.

All in all, I think a pretty safe patch.
Attachment #315203 - Attachment is obsolete: true
Attachment #315445 - Flags: superreview?(mrbkap)
Attachment #315445 - Flags: review?(mrbkap)
Attachment #315203 - Flags: superreview?(roc)
Attachment #315203 - Flags: review?(roc)
Whiteboard: [needs review]
Comment on attachment 315445 [details] [diff] [review]

Is it worth passing the metrics computed in UpdateCaretRects to UpdateHookRect? r+sr=me either way.
Attachment #315445 - Flags: superreview?(mrbkap)
Attachment #315445 - Flags: superreview+
Attachment #315445 - Flags: review?(mrbkap)
Attachment #315445 - Flags: review+
Yeah, might as well pass the Metrics down to UpdateHookRect.

This is a simple low-risk patch that apparently will fix an accessiblity issue if someone zooms out.
Attachment #315445 - Attachment is obsolete: true
Attachment #315460 - Flags: superreview+
Attachment #315460 - Flags: review+
Attachment #315460 - Flags: approval1.9?
Whiteboard: [needs review] → [reviewed patch in hand]
Attachment #315460 - Flags: approval1.9? → approval1.9+
checked in.
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [reviewed patch in hand]
Verified with as much as possible zoom levels. Works as expected with the following builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041506 Minefield/3.0pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008041504 Minefield/3.0pre ID:2008041504
Flags: in-litmus?
Hardware: PC → All
Target Milestone: --- → mozilla1.9
You need to log in before you can comment on or make changes to this bug.