Bugzilla – Full Text Bug Listing
| Summary: | [misc] Java editor does not read lines in JAWS 4.5 | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Tod Creasey <Tod_Creasey> |
| Component: | Text | Assignee: | Tom Hofmann <eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | dipalerm, Kevin_Haaland, luca.davanzo, matt, vilmar |
| Version: | 2.1 | Keywords: | accessibility |
| Target Milestone: | 3.0 M9 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 39205 | ||
| Bug Blocks: | |||
|
Description
Tod Creasey
This does not occur in the regular text editor which works fine. this problem also happens using jaws 4.02.52 I confirm this bug: any version of jaws from 3.7 to 4.51 doesnt work with java editor in eclipse 3 m1 and m2 Problem with java editor and jaws (all versions) still occurs in build 3.0 m3 Work Around for this Bug. I find that this bug is caused by the fact that the cursor in the Java editor is a left bracket. That is a bit too wide for JAWS to recognize by default. Use the following procedure to temporarily fix this: 1. While in Eclipse, press Insert+6 on the keyboard to open the configuration manager with the Eclipse config file. 2. Press Alt+S to open the settings menu. 3. Press C to open the cursor settings. 4. Tab to the Vertical Caret Maximum Width setting and change it from 3 to 5. 5. Press Alt+F4 to close the Configuration Manager and answer Yes to saving the file. This is a temporary fix. We now need to look into why JAWS does not know the position of the cursor directly instead of using the backup of looking for a blinking caret. Frank DiPalermo 512 917-0534 dipalerm@us.ibm.com So, can we conclude that the error is with JAWS only recognizing standard (i.e. line or block) carets? Yes, I guess you could say that, but I still think we need more analysis into whether JAWS should be able to find this caret position directly. Frank Ok, this workaround is quite useful, however jaws cursor tracking is often inaccurate: arrowing with left&/right arrows jaws ofte skips some characters or detect spaces where in fact there are not.. So one can never be sure of the correctness of what you hear... Using jaws 4.02 with windows nt 4.0 and windows 2000 Luca, I do not have that same behavior here. I have JAWS 4.51 and 5.0 loaded. Both seem fine. I am currently running Eclipse 20031218. Your description sounds similar to that in bug #42623. This behavior is often caused by the cursor not blinking fast when JAWS is using the blink of the caret to find it as it seems to be doing here. It would be interesting to know: 1. What version of Eclipse you have? 2. Is the cursor blinking fast in your editor? *** Bug 42623 has been marked as a duplicate of this bug. *** I am using eclipse 3.0 m6 (last available build); jaws 4.02 and below are the only version that works (higher version crash eclipse as bug 36493) Still, I find that sometimes some characters are skipped or are not shonw in Braille, some other time my Braille displays shows spaces between character where actually there are not; refreshing the screen with alt+Esc (jaws command) some times soleve the issue, some times not; I set in Jaws Config > Settings >Cursor vertical width to 4 and changed (increased) cursor blinking rate but with no effect. Actually I have to say that this problems is shown more in Braille than speech, maybe this is the reason you didint experience this defect? A few additional comments from some more testing: 1. It seems that the cursor work around is not effective with font sizes smaller than 10 point which is the default. Moving by character in smaller fonts, produces incorrect responses. 2. Apparently the shape of the Java editor cursor changed between 20030528 and the current build. It used to be a vertical bar which worked OK with JAWS and now it is a left bracket that does not. 3. I have not looked at all this in Braille, but I will in the next couple of days. You can verify whether the problem is caused by the caret by changing from the
Smart Insert mode (i.e. [ caret) to non-smart insert mode which has the old
caret. This is done either by pressing the Insert key twice or by twice clicking
on [Smart Insert] field in the status bar. If you do this only once you get into
the Overwrite mode (indicated via block caret).
>That is a bit too wide for JAWS to recognize by default.
What about the block caret? This is even wider.
Yes, JAWS recognizes the "not smart" cursor with its default settings. It also seems to solve the problems with small editors too. I could not find mention of these functions in the online help. What functions does a user lose when he is not using the smart cursor? The block cursor is not recognized by JAWS. >What functions does a user lose when he is not using the smart cursor? Almost everything ;-) e.g. most of the stuff mentioned on the Java > Editor > Typing page. >The block cursor is not recognized by JAWS. This means users who use overwrite mode can't do this in combination with JAWS, right? Sorry for my ignorance of Eclipse, but I do not understand what you mean by the Java > Editor > Typing Page. It has been my experience that most users who are blind never use overtype mode. Perhaps Matt might like to comment on that. No Problem. 1. On main menu bar: Window > Preferences 2. Expand Java node 3. Select node "Editor" 4. Click on Typing tab 1. Smart typing is essential function; we cannot give that up to have cursor tracking. 2. Use of overtype by most people is rare, but more rare for blind users because they have a hard time knowhing what they are about to type over unless they are simultaneously using braille. Even then, I find it difficult to type and follow along in braille because you are constantly moving hands between display and keyboard. The only environment In which I have regularly used overtype is terminal emulation (it is essential there). 3. We need reliable cursor tracking regardless of font setting. This is not possible with the JAWS configuration change described by Frank. 4. We do not yet know if this is standard JAWS behavior (shortcoming) or unique to Eclipse. It is well-known that you have to change the cursor in some applications to get JAWS to track it. This is to say that even if it is a JAWS shortcoming or limitation by design (of their video driver or related technology), we may have to provide some optional JAWS trackable cursor options in Eclipse. The other possibility is that there may be something that can be done in Eclipse to get JAWS (and possibly other screen readers too) to use a different more reliable way of tracking the cursor. 5. If this is a JAWS shortcoming, even if we had dedicated support at inside Freedom Scientific, it will not be quickly resolved because cursor tracking by a screen reader is such a core function (and one constantly plagued by the unexpected). Thus I think it expedient and prudent to include some means for providing optional cursors right now in the 3.0 stream. JAWS can easily track 2 kinds: blinking vertical bars and blinking underlines. Without such options, JAWS users are stuck at the 5/28/03 build of Eclipse or they must deal with such unreliable cursor tracking as to make productive work almost impossible. If we wait on what we can get done at FS, we will very likely be waiting many months past the release of 3.0. We should think about using the underline caret instead of [ given the fact that we already have PRS against [ from non-blind users (see bug 39205). This bug is fixed in JAWS 5.00.809. To upgrade, see the final comment from Frank DiPalermo in bug 36493. Closing this bug report. This bug is definitely not fixed. Crashing, performance and menu reading are fixed. But this bug is not effected by JAWS 5.0.809. Actually, it honestly works for me with JAWS 5.0.809 and Eclipse build 200402102000 - did we change something in this build, perhaps? Tod? My Vertical Caret Maximum Width in JAWS is set at 3. I seem to have all of the "Smart cursor" options turned on. Overwrite typing is not disabled or anything. So I don't think I have any of the workarounds running. Is there anything else I can check to see why this is working? Not sure - I don't work on the editors. I am going to look over this post M7 - there has been a lot of progress in M7 on a number of items in Eclipse. >I seem to have all of the "Smart cursor" options turned on.
If enabled you see a [ shape caret.
We didn't change code related to the caret recently. Maybe SWT (StyledText) did?
I tried m7 and jaws 5.00.812 with no luck. Jaws doesn't recognize cursor when smart insert mode is on. Very sorry everyone - my error. I forgot that there are TWO configuration files for JAWS - one that is application-specific (i.e. type INS+F2 when eclipse has focus), and one that is global (i.e. JAWS-specific... type INS+F2 when JAWS has focus). I just checked BOTH configuration files, and I see that the eclipse-specific one has the cursor width set to 5. When I put that back to the default of 3 pixels, JAWS did not read anything in the Java editor - which is what all of you have been experiencing. Sorry to confuse the issue. I hope I didn't waste anyone's time. I have talked to Kai (who is responsible for the [ smart insert cursor) about this problem, and here is what he said: "For M8 we will revisit the caret shape. The smart mode might go back to the normal caret shape. I'll come back to you when this will happen to ensure that screen readers are satisfied with the solution." I didn't use JAWS so far so please forgive me if this sounds stupid: couldn't we ship an eclipse-specific configuration file that has the cursor width set to 5? As mentioned in comment 22 this seems to fix the problem. This cursor width setting is in the JAWS configuration not Eclipse. Shipping JAWS configs, Window-Eyes confis, etc., is not a good path to go down for a variety of reason. Besides, it doesn't really fix the problem; it just changes its nature. Even with the cursor width setting changed in JAWS, JAWS still sometimes reports blanks where there are not blanks and still cannot handle smaller than 10 point font. I don't know if Window-Eyes has the same ability to change the cursor width for which it is looking. We will change the cursor of the smart insert mode to the default caret. We intent to change the default caret width to be 2 pixels rather than 1. Does this cause any problem with JAWS? We will also provide an option to always use the default caret independent from the mode you are in. A caret that is two pixels wide should be OK, so long as it does not infringe on the character's pixel box. I assume that it would change size as the font changes? Also, you might be careful of a two pixel caret and the character pixel box with very small fonts. see bug 39205 fixed > 20040401 - caret for smart mode (default) is standard ibeam - a special caret will only be shown in overwrite mode and raw (dumb) mode - special carets will be disableable for accessibility - by default the caret is two pixels wide, but this can be disabled I have just downloaded and installed build 200404060800 and find the following cursor implementation: The default Java Editor is 2 pixels wide. JAWS works just fine with it. There are two settings in the Java Editor preferences: A checkbox that says use only standard caret. The default is unchecked. A checkbox that says enable thick caret. The default is checked. I unchecked the thick caret setting and found the normal vertical bar caret. It works fine with JAWS too. Then I changed the Java Editor font to a 5 point Terminal font. JAWS still read everything just fine, even with the two pixel caret. I also noted that the size of the caret changed on the fly with the size of the font, so that's fixed too. Excellent - thanks for the feedback, Frank. Verified using JAWS 5.0 and build 20040520 |