GNOME Bugzilla – Bug 520612
Cursor routing key support in firefox
Last modified: 2009-03-10 00:04:44 UTC
Firefox does not support cursor routing keys. This is because document content is displayed with braille.Region, instead of braille.Text. braille.Region does not support cursor key routing.
Created attachment 106725 [details] [review] Proposed changes This is the beginning of work that might work. I didn't test this thoroughly, but cursor key routing should work.
First coarse pass at GNOME 2.24 planning.
Created attachment 107577 [details] [review] Proposed patch Added pydoc strings.
Created attachment 107578 [details] [review] Proposed patch This patch depends on the patch in bug 523268. I separated them so it's all a bit more clear.
Can you give me an idea of where this patch stands? Is it still proof of concept? One thing I noticed is that the gnome-terminal fix seems broken -- in looking at the patch, I don't see any return values from the new getTextLineAtCaret method.
Created attachment 107644 [details] [review] Proposed patch Yes, this is still a proof of concept. This fixes the gnome-terminal issue. I hope to come out with more functional patches before we actually consider committing this.
Created attachment 107764 [details] [review] Proposed patch This patch adds support for flat review, this includes cursor routing, just like any other text area, so you could click on the character you want to go to from flat review. It also supports link component regions, so if you click on the "Link" region in the braille display, the link will be activated.
Mike, could you give this a spin and tell me what you think? If you find a bug in your paypal account page, I will need your username and password :)
One thing I think we'd like to change here is to make a cursor routing press on a link or form control perform a mouse click. This would for example allow for the clicking of links or activation of buttons.
That should actually work. I didn't want to enable it for clicks on the actual text, because the user might not know it is a link, and just want to move the caret. But if you lick on the "Link" text, it performs a click. Do you think the former should be the behavior? I didn't do the form control part, good idea.
Created attachment 108031 [details] [review] Proposed patch This patch enables clicking on links, not just on the Link identifier, but the entire text. Also, forms seem to just work.
Created attachment 108575 [details] [review] Proposed patch This has some changes that are a bit less intrusive.
Changes committed to trunk. Unless something horribly wrong happened because of this patch, please file a new bug if there are more issues.
This isn't "horribly wrong" but your patch introduces a regression (as discovered via the regression tests). We are now displaying certain embedded object characters that we weren't before. For example, navigate by line or by tabbing on the anchors2.html test file. I'm not sure if your change exposed something bad/wrong in the way we were doing things or not. One way or another we need to fix it. I'm tired and will investigate tomorrow sometime, unless you beat me to it. :-)
A couple of other symptoms/regressions found via the regression tests which need to be examined: Cursor at the end of the list rather than the beginning of the list, for example: Test 3 of 16 FAILED: /home/jd/orca/test/keystrokes/firefox/html_role_lists.py:Line Down EXPECTED: "BRAILLE LINE: '1. remember what the heck we are doing each day'", " VISIBLE: '1. remember what the heck we are', cursor=1", "SPEECH OUTPUT: '1. remember what the heck we are doing each day'", ACTUAL: "BRAILLE LINE: '1. remember what the heck we are doing each day'", " VISIBLE: ' the heck we are doing each day', cursor=32", "SPEECH OUTPUT: '1. remember what the heck we are doing each day'", Missing characters (e.g. the 'r' in 'rather' and the ':' at the end of 'here'): Test 41 of 41 FAILED: /home/jd/orca/test/keystrokes/firefox/label_guess_entries.py:Next form field EXPECTED: "BRAILLE LINE: 'Type something Link rather amusing Link here: $l'", " VISIBLE: ' $l', cursor=1", "SPEECH OUTPUT: 'Wrapping to top.'", "SPEECH OUTPUT: 'Type something rather amusing here: text'", ACTUAL: "BRAILLE LINE: 'Type something Link rathe amusing Link here $l'", " VISIBLE: ' $l', cursor=1", "SPEECH OUTPUT: 'Wrapping to top.'", "SPEECH OUTPUT: 'Type something rather amusing here: text'",
I'm going to revert this patch for the time-being. I knew it would show problems, I just didn't realize how fast.
I am chasing down a lot of fundamental stuff. So I don't think I am going to fix this in trunk. Rather I will improve the patch here. Sorry about all that.
Created attachment 108892 [details] [review] Proposed patch Ok, the changes here should fix the regressions joanie mentioned above. Joanie, could you give this a round of tests? The firefox tests directory always stops working at some point, I think it's all those dojo tests. Do you run all of them?
Eitan, I'm really sorry I didn't see/notice this comment when you asked it. :-( We discussed this at team meeting, but for the sake of documentation: The tests do not *normally* stop working at some point, but every once in a while I find that a test does cause the suite to get hung up. Running them this afternoon, it got hung up on dojo_checkbox.py. When this happens, I give focus to the terminal window where I launched the tests and press Control C just once. That seems to kill the current test without killing the suite. And, sure enough, that worked today. :-) Anyhoo.... Looking at the tests, there are quite a few "regressions" (note the quotation marks) that are arguably fixes because they are the removal of unnecessary and unwanted whitespace. (Yea!!) A few examples: ~~~~~~~~~~~~~~~ - BRAILLE LINE: 'Foo Link ' ? - + BRAILLE LINE: 'Foo Link' ~~~~~~~~~~~~~~~ - BRAILLE LINE: 'I know how to cope with misfortune, ' ? - + BRAILLE LINE: 'I know how to cope with misfortune,' ~~~~~~~~~~~~~~~ - BRAILLE LINE: ' $l and Now $l ' ? -- + BRAILLE LINE: ' $l and Now $l' ~~~~~~~~~~~~~~~ - VISIBLE: ' < > CheckBox and remember th', cursor=1 ? --- - + VISIBLE: '< > CheckBox and remember these ', cursor=1 ? ++++ ~~~~~~~~~~~~~~~ I don't see any true regressions (i.e. in the breakage sense of the word). :-) Therefore, if this works in terms of cursor routing, my vote would be to get this patch checked in. Once that has occurred, I'll update the regression tests to reflect the removed whitespace.
Thanks for that Joanie! I committed this to trunk. Closing bug. If you think these changes are the culprit of future regressions, please open a new one. Tanks!