271785 - Unfixable blinking cursor in text boxes causes neurological problems for some people

Status: RESOLVED WORKSFORME

(Core :: General, defect, P4)

Description

[t t]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041119 Firefox/1.0 (Debian package 1.0-3)
Build Identifier: Both Mozilla and Firefox (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041119 Firefox/1.0 (Debian package 1.0-3))

Every text box in Mozilla and Firefox uses a blinking cursor.  This causes
neurological problems for some people who are stimulation-sensitive such as myself.

(Yes, there is such a thing.  No, it is not just epileptics.)

ALSO, in most configurations, it is true of UI text boxes such as the search bar
or the URL bar.


Reproducible: Always
Steps to Reproduce:
1.  Go to a web page with a text box, such as Google or this bug report page.
 
OR

2.  Click anywhere in the URL bar.

Actual Results:  
That's personal, but it causes problems that are serious enough to warrant a change.

I often use other browsers simply to avoid this problem.


Expected Results:  
Please allow the user to make is possible that -- or set as the default that --
the text box cursor does not blink but instead is a colored inverse-video box
about 1 em wide, on the character immediately following the insertion point.

For extra credit (i.e. nice but not necessary) if the insertion point is at the
end of the line, then have the box appear different, perhaps half-width, to
differentiate from being over a space at the end of the line.

Emacs, DOS command prompt, and Unix shells are all configurable to do this, but
some shells do not do the extra credit.

Please note that this issue is different from the "cursor" that exists for text
that is not in a text box.  By default that cursor does the same thing, but I
was able to disable it by turning off that cursor entirely.  Doing so does not
and should not turn off the text box cursor because the text box cursor is
necessary to determine where changes will be made.

It is also different from blinking text done by overzealous web page designers.
 That seems to be fixable either in about:config or in a user style sheet.

This bug is NOT fixable without you the elite programmers fixing it, as far as I
can tell.

As for the UI text boxes (as opposed to web page text boxes) it is far from
clear whether it is possible to make it do what I propose using Windows, KDE,
Gnome, or other environments.  I believe that it is not possible in all of those
environments.  I think the setting should apply to both web and the UI and apply
to all environments, and the user should not have to figure out how to make the
OS do it (even if it were possible).


Same on Linux and Windows as far as I can tell.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Do you have examples of other browsers that do this? It would be valuable to see
how others implement it. I think making this change would involve quite a bit of
work.

Comment 2

[t t]

to gavin.sharp
	 More options	 8:09pm (59 minutes ago)

Sorry to mail this directly, but I don't think you have seen it.  I
got email with your comment, and replied to it, but it did not show up
in the bug.  What am I doing wrong?  Do I have to use the web
interface every time?

---------- Forwarded message ----------
From: t takahashi <[e-mail]>
Date: Thu, 25 Nov 2004 18:13:56 -0700
Subject: Re: [Bug 271785] Unfixable blinking cursor in text boxes
causes neurological problems for some people
To: "[e-mail]" <[e-mail]>

Thanks for replying.  Sorry for gmail's wrapping below.

On Thu, 25 Nov 2004 16:04:39 -0800, [e-mail]
<[e-mail]> wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=271785
> Do you have examples of other browsers that do this? It would be valuable to see
> how others implement it. I think making this change would involve quite a bit of
> work.

Well, elinks and w3m are examples of browsers that I use to avoid the
problem, but I REALLY want to use firefox, partly because it works
with more web pages (e.g. ones with javascript) and has a standard
engine, and partly because I like it otherwise (and it's going to take
over).

Other gecko browsers have the problem also, and so does Konqueror,
which is my only other serious GUI option that I know of.
(Have not tried Opera.)

So I'm really stuck and hoping that if you guys can get this
implemented in Firefox 1.x then I won't have to live with the problem
for many years in the future.  And FF would rock as a browser known
for being accessible to a wide range of people.

Why would it be hard?  I wish I could help, but I can't.

If it's REALLY hard, then just having the cursor be steady would still
help, even if it not a block cursor the way I suggested.

FWIW Google found this for me, which might or might not be relevant
(don't know how to set it as a user, and don't know if FF uses GTK+ or
its own cross-platform library or something else):
http://www.freedesktop.org/wiki/Standards_2fXSettingsRegistry?action=show
It is too bad that even that project doesn't allow the block cursor,
but at least it allows turning off the blinking.  I tried editing the
page to make the suggestion, but it wasn't editable.  FF could really
pioneer this.

P.S.  In my report when I distinguished the problem from the caret, I
mistakenly used the word cursor.  The caret can be disabled by the
user; the cursor cannot be fixed by the user, which is the problem.

Comment 3

[timeless]

reporter:
1. you need to use the web interface.
2. please provide some sort of url which describes the neurological problems
you're describing, preferably from a reputable source.

Comment 4

[t t]

(In reply to comment #3)
> reporter:
> 1. you need to use the web interface.

OK

> 2. please provide some sort of url which describes the neurological problems
> you're describing, preferably from a reputable source.

OK, I'll do what I can below.  Hope it helps.  I only know of this from personal
experience (it's real), what doctors tell me about many others experiencing the
same thing, and other people I have met who also experience it, so my google
search will be not much better than yours would be, but here goes.

Blinking cursors can cause problems in fibromyalgia and related conditions, in
migraines, and in some unusual cases, epilepsy (rare below 8Hz).  There might be
neurological conditions I'm not aware of also, and effects on performance by
people who are easily distracted via ADD or other factors.  People with PTSD are
are often stimulation-sensitive (although I don't know whether it extends to
slight stimulations like cursor blinking), and there are diffuse categories of
"sensitive people" who have not yet been given the dignity/indignity of a
diagnosis (I have not looked into it, but there are books).  Stimulation
sensitivity can definitely arise as a consequence of severe sleep disorders. 
Very rarely, but definitely, a viral infection can cause stimulation
sensitivity, although the main viral case I am thinking of probably mostly only
lasts for a few weeks.

Regardless of the cause, stimulation sensitivity is perhaps best imagined by a
normal person as pulling an all-nighter, then having a severe hangover on top of
it.  In such a case you might be able to see how an otherwise trivial thing like
a blinking cursor could be a problem.  Sensitivity to fluorescent lights and
loud noises and touch are often comorbid.  Have you ever felt that way, perhaps
after a long coding session?  Some people are like that most or all of the time,
not by their own choosing.

OK, with that out of the way:

Lots of people with fibromyalgia have the problem and it definitely extends to
blinking cursors.  A quick search located this: "The slightest sensory
stimulation -- even being touched when putting on
clothes -- can be highly painful in people with fibromyalgia," says
Laurence A. Bradley, a fibromyalgia expert at the University of Alabama at
Birmingham. "We suspect there are abnormalities in both the pain
transmission and pain inhibition system.".
http://fmscommunity.org/nl38.htm

Some people with migraines experience it.  Another quick search located this:
"Other triggers include environmental factors such as: temperature changes,
humidity, bright or blinking lights".
http://216.239.57.104/search?q=cache:MfWTo98GO-kJ:teacher.scholastic.com/researchtools/articlearchives/humanbody/headaches.htm&hl=en

Epilepsy is rare at this frequency, but a quick search located this, for what
it's worth: "Adjust the display intensity on the monitor, the blinking cursor
can be reduced by changing the configuration of the DOS SHELL or by purchasing
software that reduces eliminates or enlargers the cursor. ".  "Job Accommodation
Network. (undated) “Case Summaries.” A service of the President’s Committee on
Employment of People with Disabilities. Morgantown, WV."
http://www.wid.org/archives/telecom/appendix2j.html

(Of course, it's a bit easier to find reports of people having trouble with it
on web forums, but you might consider that too anecdotal? (Although I'll not
present those ones, I hope that you would not have been too put off by them,
since even an anecdotally-presented medical problem that solely makes somebody
have to occasionally or frequently quit using the software is at least no less a
problem than, say, an anecdotally-presented user interface problem that somebody
describes in a bug report about a behavior that some users find so non-intuitive
or annoying (i.e. they don't like it) that they quit using the software; user
interface authorities are not usually consulted for such cases, so all else
equal, it would be not in keeping that a medical authority would be sought for a
medical problem, putting an additional burden on the requestor.  If you are
skeptical that such a thing exists at all, I hope this comment helps assuage
your skepticism at least a little.))

Overall, I believe that there is a reason that DOS, Emacs, Unix shells, and
various terminals make the choice to allow variety in cursors (I think that even
hardware terminals allow for variety of cursor types).  I don't think
preferences in this matter are merely a minor aesthetic point, but every bit as
important as double-click rate (important for people who cannot click fast
enough -- that's accepted by most aware software developers) and any sort of
distracting elements.  I note that there is a Firefox extension that disables
the throbber and many add-on programs for the likes of DOS that let you fix the
cursor.  I don't think it's a trivial issue at all, no matter how bizarre it
might seem at first.

Even the size of the cursor matters.  Some people find it hard to locate a
vertical bar cursor or a small pointer.  I don't know if reputable web sites
discuss that, but it's pretty obvious that it is a problem, and that is why some
add-on packages fix it, such as big-cursor for Debian.  Reputable web sites or not.

I could search more, but I am very limited in how much I can do that (have done
FAR too much already), so I have to stop.  These might not be the authorities
you were looking for, but I hope that you see that it is something worth doing
if it is even partly possible to fix.  If not, I don't know what I can do to
convince you.  People with even mildly unusual conditions face an uphill battle
trying to convince people that they should be taken seriously, day in and day
out.  Being asked for justification can get really old after a while, even if
it's reasonable for the person asking.  I hope I haven't been too defensive at
your request for web sites.

By the way, the problem is affecting me right now since I have to use a GUI
browser to add to this bug report. I know for certain that I am not alone.

Comment 5

[t t]

By the way, why do I always get zarro boogs found when I try to get to my bugs.
 I have an email address with a "+".  Is that definitely somehow it?

Comment 6

[t t]

By the way, please keep the about:config setting that lets you turn off the
(blinking) caret that appears in non-text-box.  That is very valuable.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #5)
> By the way, why do I always get zarro boogs found when I try to get to my bugs.
> I have an email address with a "+".  Is that definitely somehow it?

The "My Bugs" doesn't display bugs that are in the "Unconfirmed" state, like
this one. Only "New", "Assigned" and "Reopened" bugs get displayed there.

> By the way, please keep the about:config setting that lets you turn off the
> (blinking) caret that appears in non-text-box.  That is very valuable.

Are you referring to accessibility.browsewithcaret ?

Comment 8

[t t]

> > By the way, please keep the about:config setting that lets you turn off the
> > (blinking) caret that appears in non-text-box.  That is very valuable.
> 
> Are you referring to accessibility.browsewithcaret ?

Yes, it is that one (I tried it both ways).  I don't know what the caret is
useful for, but I have not needed it.

(I'm not sure how to tell exactly which changes one has made from the defaults
using .firefox or .mozilla.  I'm guessing that prefs.js contains the information
somehow, possibly by absence.  It would be great if there were one file with
one's settings and one file with the default settings, so that you can do a diff
anytime you wanted to tell, and also so that whenever FF upgrades it would be
easy to tell whether the defaults have changed in the new version of FF.).  (BTW
it would also be great if there were descriptions of each item in about:config,
but I'll bet others have already suggested that one about a million times :-).)

Thanks.

Comment 9

[t t]

(In reply to comment #8)
> Yes, it is that one (I tried it both ways).  I don't know what the caret is
> useful for, but I have not needed it.

Ohhhh.  I just figured out two uses for it: (1) remembering where you were in a
page, and (2) telling you where the last line was before you scrolled in the
case where the last page is less than a full page so that you do not have to try
to figure out which lines you have already read.  (2) (i.e. highlighting the
last line of the previous screen after a scroll) would be VERY useful, but would
have to be non-blinking (e.g. inverse video on the last line of the previous
screen or as a non-blinking line on the left side) of course.  I realize this is
a digression, but that would be a really useful feature :-).

Comment 10

[Aaron Leventhal]

This will stop your caret from blinking:
ui.caretBlinkTime    0

This will change the width of your caret to 3px
ui.caretWidthTwips   3
In future versions it has been renamed to ui.caretWidth because it is not really
measured in twips. Unfortunately the caret grows from right to left, which makes
it partially cover up the current character. The best width is probably 2. It
does invert whatever it covers.

Comment 11

[t t]

(In reply to comment #0)

By the way, in case this clarifies or helps in any way: UI text boxes (such as
in the URL bar or the search bar) are much less of a problem than the text boxes
that appear in web pages, because the cursor is rarely in the UI (at least IME,
modulo possible fancy extensions etc.).

Thanks for the note about the caret.  I don't use it, but it's great to know
that it can be made solid.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

You must be confusing terminology here, because Aaron's comment addresses the
caret, which is the thing that appears in web page text boxes (<TEXTAREA>,
<INPUT TYPE="text">, etc) as well as the UI boxes (location bar, search bar) to
indicate the position when typing. It's also what appears on sites when you have
caret browsing turned on. They are the same thing. Those prefs works for both.

If you are thinking about something else, feel free to elaborate, but this seems
to me like it's INVALID.

Comment 13

[t t]

(In reply to comment #12)
> You must be confusing terminology here, because Aaron's comment addresses the

Seemingly.  I was trying to adapt to Mozilla's terminology and describe the
separate places where cursor-like things blink, so as to file the *absolutely
most clear bug report possible*.  That backfired.

Here is why: IMHO most technical people outside of Mozilla, including myself,
say "cursor" for all intra-text, unique, movable, visible position indicators
and reserve "caret" mostly for the circumflex "^" character, but I see now that
(1) the correct Mozilla term is "caret" for all such indicators, and (2) the
correct Mozilla way to distinguish the indicators from each other is to describe
the situations in which they appear.  "Caret" threw me off because I thought
that its very unfamiliarity was for the purpose of disambiguating caret-browsing
cursors from text-box cursors, just as we say "throbber" instead of "icon". 
Apologies.

> caret browsing turned on. They are the same thing. Those prefs works for both.

Those prefs must be brand new, because "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7.5) Gecko/20041128 Firefox/1.0 (Debian package 1.0-4)" doesn't have them.

I can't wait to try it.  Was it prompted by this bug report or just good timing?

> If you are thinking about something else, feel free to elaborate, but this seems
> to me like it's INVALID.

I won't be able to tell how well it works until I try it.  I didn't realize that
I was that far behind in the versions.  For completeness: too bad about growing
from right to left (other box cursors grow the other way), but that should be
easier to get used to than blinking, at least for me.  I just realized that
there might or might not be an issue with proportional text, but if so, it
should be a minor one compared to blinking and width control with inverse colors
in the first place.  And extra credit is of course optional.  So assuming that
all the cursors are non-blinking it will probably be a huge improvement.

Thank you *very much* for paying attention to this issue.  And thank you to the
developer if it was just a coincidence.  I will try the new feature as soon as
it appears in Debian unstable.  Do I need to do anything to this bug report once
I try it?

Comment 14

[t t]

(In reply to comment #10)
> This will stop your caret from blinking:
> ui.caretBlinkTime    0
> 
> This will change the width of your caret to 3px
> ui.caretWidthTwips   3

Can you give me a version number for the version these are in?

Thanks.

> In future versions it has been renamed to ui.caretWidth because it is not really
> measured in twips. Unfortunately the caret grows from right to left, which makes
> it partially cover up the current character. The best width is probably 2. It
> does invert whatever it covers.
> 

Comment 15

[Aaron Leventhal]

(In reply to comment #10)
> This will stop your caret from blinking:
> ui.caretBlinkTime    0
This has been around for a while. Mozilla 1.7 should have that.

> 
> This will change the width of your caret to 3px
> ui.caretWidthTwips   3
This one doesn't work well at larger widths anyway, but I think it's in 1.8a5.

Comment 16

[Aaron Leventhal]

Since we follow OS settings and also have a workaround about:config solution I
suggest WONTFIX. This isn't ever going to make it into the main prefs panel.
Perhaps it's a good extension.

Comment 17

[t t]

(In reply to comment #15)

> > ui.caretBlinkTime    0
> This has been around for a while. Mozilla 1.7 should have that.

I filed the bug against Firefox.  Which version of Firefox should have it?  I
have been waiting for it to appear, but it has not appeared yet.  I only use
Firefox.

I do hope it was fixed in Firefox.

Thanks.

> > This will change the width of your caret to 3px
> > ui.caretWidthTwips   3
> This one doesn't work well at larger widths anyway, but I think it's in 1.8a5.

Is that a Firefox version?  Won't work at larger widths?

Thanks.

Comment 18

[Aaron Leventhal]

We don't have an official release build of trunk firefox yet, but try a nightly
build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

All bugs should be filed against the latest trunk, not against 1.0. That uses an
old version of Gecko. Only reopen this if you've tested and caret blinking can't
be turned off in nightly Firefox. Thank you.

Comment 19

[Jesse Ruderman]

*** Bug 330419 has been marked as a duplicate of this bug. ***

Comment 20

[Jesse Ruderman]

Reopening based on the request in the dup.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Confirming, and requesting blocking, since it sounds like we regressed something so that blinktime = 0 doesn't show a caret at all....

Comment 22

[Damon Sicore (:damons)]

Marking as blocking 1.9.  I think we should take this seriously.

Comment 23

[Blake Kaplan (:mrbkap) (inactive)]

Putting on my list, but it's going to be a little bit before I get to actually look at this in any depth.

Comment 24

[Blake Kaplan (:mrbkap) (inactive)]

Marking as P3 -- if anybody wants to jump in here, I bet the fix will be in nsCaret.cpp.

Comment 25

[Blake Kaplan (:mrbkap) (inactive)]

Jet, can you decide what to do with this bug (since it's pretty clear at this point that I'm not going to get to it)? Looking around, it appears that at least on Windows and Linux, we should respect the system setting to make the caret not blink, so this bug might be mac-only at this point.

Comment 26

[Jet Villegas (inactive)]

Seems to be related to the Mac code not querying the system for the blink interval:

See "eIntID_CaretBlinkTime" in these two files to compare:

widget/cocoa/nsLookAndFeel.mm
widget/windows/nsLookAndFeel.cpp

I see a similar static value for other platforms (Android, B2G) as well. I take it that we want to use blinktime as the default, and not 500?

David, are we getting a lot of A11y calls on this one? It seems Mac OSX doesn't even have a system level control for this, other than some terminal voodoo:

http://stoictopia.wordpress.com/2010/12/01/how-to-disable-cursor-blink-rate-in-mac-os-x/

Comment 27

[David Bolter [:davidb] (NeedInfo me for attention)]

I haven't had any direct complaints about this bug but we definitely want to do the right thing here.

Comment 28

[Jet Villegas (inactive)]

Setting ui.caretBlinkTime to 0 or -1 in about:config is the documented way to do this across all platforms. I just confirmed this works on the Mac. Closing.