Bug 100034 - [PropertiesView] read text doesn't match displayed text in comboboxes within Properties view
Summary: [PropertiesView] read text doesn't match displayed text in comboboxes within ...
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Eric Moffatt CLA
QA Contact:
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2005-06-14 14:07 EDT by Nick Boldt CLA
Modified: 2008-04-21 13:49 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Boldt CLA 2005-06-14 14:07:25 EDT
Eclipse 3.1RC1
IBM Desktop Reader 3.0.4
EMF 2.1.0 (latest available I driver) [optional]

Steps to reproduce: 

Launch Eclipse. Run steps in EMF tutorial. When you get to the steps involving
making changes in the Properties view, turn on IBM Desktop Reader, and navigate
w/ keyboard as noted below.

--

In one case, the reader reads the previously selected text - Mystery - when I
select Biography instead (when editing a .library file in the generated editor
in the associated Properties view). In another (editing properties on a
.genmodel file), it says either "selected" or "not selected" as I cursor up/down
but doesn't line up with the value that's actually selected. 

In both cases above, when you cursor left/right, it reads the chars of the value
that WAS selected, not the char of the displayed entry. Home/End work too, but
again, read the value of the text that was in the field before any up/down
changes occurred.

The workaround, if you can call it that, is to cursor up/down to the entry you
want to change, as it reads Property names. Then hit enter to edit, cursor
up/down and hit enter. It'll approve the change, read the Property name again,
and if you hit enter a second time, it'll read the Property's *new* value this
time. So you end up setting/checking/resetting/checking iteratively until you
find the value you want - painful, but almost usable.
Comment 1 Nick Boldt CLA 2005-06-14 14:10:35 EDT
Alternative steps to reproduce:

open any .exsd file, then open Properties view, and use the Deprecated property
to see the above mentioned behaviour. When changing from false to true, for
example, the read text is either "false" (beginning of text) or "fals" (end of
text) since the displayed text is "true" therefore the read text is truncated to
4 chars as well. 

The above workaround works here too, but is equally clunky.
Comment 2 Karice McIntyre CLA 2006-12-04 09:45:08 EST
Eric, what is the status/target of this bug?
Comment 3 Eric Moffatt CLA 2006-12-07 16:20:37 EST
I'm currently swamped with min/max and commands work and may not get to this very soon.
Comment 4 Eric Moffatt CLA 2006-12-11 10:44:16 EST
Nick, does this happen for -every- property of a given type (text, combo...) or only on some? I'm trying to see if it indicates a broken updating mechanism in the CellEditors, something in the viewer or something specific to a particular propetry within the cnotext..

thanks
Comment 5 Nick Boldt CLA 2006-12-12 10:44:50 EST
No idea - I opened this bug 18 months ago. ;-) Have you followed my 'steps to reproduce' to, uh, reproduce the effect in order to test your fixes against it? I presume this problem continues to exist in both the 3.2.2 and 3.3 branches, if this bug is still open.

Here's some .exsd files I found with a 3-second Google search that should work for verifying the condition still exists and how widespread it is, per your question:

http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.wsvt/plugins/org.eclipse.wst.wsdl.validation/exsd/?hideattic=0#dirlist

Thanks!
Comment 6 Eric Moffatt CLA 2007-01-03 13:18:13 EST
Nick, I'm running 3.3 M4 base eclipse and I dont' even -get- property sheet entries when editing an '.exsd' file...

Maybe it's changed since 3.1 ?
Are you using base eclipse or do you have other plugins loaded?
Comment 7 Karice McIntyre CLA 2007-01-03 13:49:32 EST
Eric, the original description says Nick was using EMF 2.1.0.  I presume there is a more recent version by now though.

Nick, have you tried other screen readers like JAWS or Window Eyes?
Comment 8 Eric Moffatt CLA 2007-01-03 14:33:13 EST
Hmmmm, this may have been removed by the PDE folks when they started using 'Forms'-based editing (i.e. rather than using hte property sheet they provide controls on the right hand side that allow direct maipulation of the property values).

This may be a stale defect...Nick?
Comment 9 Nick Boldt CLA 2007-01-03 20:25:48 EST
Given I can't reproduce this effect for the described steps in Comment #1, I'm going to have to reinstall some text reader to verify if this still exists as a problem. Only snag is I'm now running Linux, not Windows, so I might not be able to reproduce it with my current environment. Are there any FVT testers out there who can run through the first or second EMF tutorials (http://www.eclipse.org/emf/docs/#tutorials) to see if the effect described has been fixed?
Comment 10 Nick Boldt CLA 2007-01-03 20:27:56 EST
I should note that when I say 'cannot reproduce' I mean using EMF 2.3 and Eclipse 3.3; I'm sure the effect is still there when using the two-year-old EMF 2.1 and Eclipse 3.1, though I've never tried with EMF 2.2 and Eclipse 3.2.
Comment 11 Eric Moffatt CLA 2008-04-21 13:49:41 EDT
Marking fixed as per Nick's last comment...