Can't make caret visible in browser

RESOLVED FIXED in mozilla0.9

Status

()

defect
P3
major
RESOLVED FIXED
19 years ago
19 years ago

People

(Reporter: aaronlev, Assigned: aaronlev)

Tracking

(Blocks 1 bug, {access})

Trunk
mozilla0.9
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

I need to be able to view the caret in the browser for debugging purposes.
The project I need this for is Mozilla for blind users. I always need to know 
where the collapsed selection is. I also need to make sure it moves with regular 
arrow key presses.
Hey, Aaron :-) How come you don't have proper Bugzilla privs? Anyway, fixed.

Confirming for evaluation.

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Simon,
There seems to be a related problem.
I've also found it impossible to extend the selection in the browser using:
/* This code works in the editor */
var controller = 
 document.commandDispatcher.getControllerForCommand('cmd_selectCharPrevious');
controller.doCommand('cmd_selectCharPrevious');
Do you think this is the same bug?
No, different bug. cmd_selectCharPrevious will only work in editors (text fields, 
composer).
Is there any way to tell the browser that you want to register a selection
controller (not an editor controller) on it?  Keyboard-only users will need
commands like selectCharPrevious in order to extend the selection via the
keyboard.
Ooops, so I lied. There should be a controller for the browser window that 
handles cmd_selectCharPrevious and friends. See
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#4731
should this be RTM? It seems like a user accessability issue, is this important 
enough for rtm?

anthonyd
Target Milestone: --- → Future
setting to future, with the understanding simon can knock it to m19 if he feels 
this is important to the rtm release.

anthonyd
Keywords: access
Mozilla0.9.
Target Milestone: Future → mozilla0.9
Actually, this shouldn't be just for debugging purposes, it should be a visible 
option -- otherwise users who can't use a pointing device will be practically 
unable to begin a selection, since they can't see where the caret is.

With this option turned on, the arrow keys should move the caret rather than 
scrolling the viewport.

Blocks compliance with UAAGs (bug 24413), checkpoint 1.3.
Blocks: uaag
Actually, I have managed to fix this myself with a few hints from Akkana.
(Thanks akk).

The only problem now is I'd like to gray the caret out for readonly textfields
and for the browser. I wanted to use nsICaret::SetCaretReadOnly(PR_BOOL) to set
this state, which doesn't really work. I think the problem is that there is one
global system caret, so as soon as the focus goes to the URL bar, the readonly
setting changes to false. Therefore the readonly state would need to be tracked
in more places, or by the focus manager. Do I have this right?
You need to set and unset the caret's readonly state just as the caret width is 
set and unset; indeed, perhaps you could generalize the call to SetCaretWidth to 
SetCaretProperties or somesuch.
Over to Aaron, who has a grasp on this.
Assignee: sfraser → aaronl
Status: ASSIGNED → NEW
*** Bug 65038 has been marked as a duplicate of this bug. ***
I'm almost done with this fix.

This allow users of screen readers and other accessibility
tools to browse Mozilla as if it's a read-only editor. 

Rather than arrow keys scrolling the page up, down, left and right, they move a
visible caret. Shifted movement keys highlight a selection. This way selection
can be done without the mouse. This involves changes to nsGlobalWindow.cpp and
htmlBindings.xml.

The visible caret is set to "readonly" so that it's gray and doesn't blink. This
indicates to the user that no data entry is allowed. This involves changes in
nsCaret.cpp.

If the user presses tab or shift-tab, the focus is moved relative to the
position of the caret. In addition, whenever the focus moves, the caret is
placed at the start of the focus. When the user moves the caret over a link, the
link is focused. This involves changes in nsEventStateManager.cpp.

I'm 90% done with this coding. All that remains is to ensure the readonly state
is properly maintained when focus changes.
@@ -2944,6 +3080,40 @@
...
+        if (!aContent) {
...
+          }
^ inconsistent {} indentation relative to file
v Please avoid this. Just add an extra line at the end.
\ No newline at end of file
Index: layout/events/src/nsEventStateManager.h

+  else
   mRendContext->SetColor(NS_RGB(255,255,255));

RCS file: /cvsroot/mozilla/layout/xbl/builtin/htmlBindings.xml,v
is it me, or do you reget the pref object for each key? that sounds expensive.

note to self[not your bug] 
nsCAutoString(sCopyString).EqualsWithConversion(aCommand)
is yucky.

fwiw, would you mind if i created an access.js for accessibility prefs?

otherwise, your stuff looks cool :-)
nsEventStateManager.cpp:
I'd suggest factoring the code under the if (mBrowseWithCaret) tests, especially 
the key handling blocks, into new, protected methods. It leaves the rest of the 
code much more readable.

Possible leak here:

+          nsIDOMRange* newRange;
+          nsresult rv = rangeDoc->CreateRange(&newRange);
+          if (NS_SUCCEEDED(rv)) {
+            // If we could create a new range, then set it to the current focus 
node
+            // And then collapse the selection
+            newRange->SelectNodeContents(currentFocusNode);
+            domSelection->AddRange(newRange);
+            domSelection->CollapseToStart();
+          }

Fix this:
+}
\ No newline at end of file


htmlBindings.xml
+      <handler event="keypress" keycode="VK_LEFT" modifiers="control" command=
"cmd_wordPrevious" />
+      <handler event="keypress" keycode="VK_RIGHT" modifiers="control" command=
"cmd_wordNext" />
etc
Don't you need platform-specific bindings here? Mac's word-move is option-arrow.
> Don't you need platform-specific bindings here? ...

Does this mean there will be *three* different places where keybindings for text 
navigation are stored -- one for read-only HTML (as created by this bug), one for 
Composer, and one for XP Toolkit? Surely that's just asking for unintentional 
inconsistency -- it already caused bug 66135, for example. Smells like some 
refactoring is needed.
OS: Windows NT → All
In GlobalWindow's ctor, you need to init mBrowserWithCaret to PR_FALSE in case 
the getting of the prefs service fails. Otherwise, r=sfraser
Looks good: break up some of the dense code with a bit of vertical whitespace
and be sure to use brace style consistent with the rest of the file. Be sure not
to monkey with user-agent string in all.js. Maybe note/comment how to extend
CaretFollowsFocus() to handle new tags in the future. Do that stuff, and sr=waterson
And please use direct initialization instead of copy (see 67860).
Fix checked in to tip.
To test, add line to prefs.js
user_pref("accessibility.browsewithcaret",true);
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.