Summary: | [Forms] MSAA problems with FormText - Tabstop without Focus | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Michael Burkhart <mikelb> | ||||||||||||
Component: | User Assistance | Assignee: | Adam Archer <agarcher> | ||||||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
Severity: | major | ||||||||||||||
Priority: | P2 | CC: | cbeth, cgold, dejan, jim_mickelson, philippe_mulet, raji | ||||||||||||
Version: | 3.3 | Keywords: | contributed | ||||||||||||
Target Milestone: | 3.4 M2 | Flags: | agarcher:
review?
(dejan) |
||||||||||||
Hardware: | PC | ||||||||||||||
OS: | Windows XP | ||||||||||||||
Whiteboard: | |||||||||||||||
Attachments: |
|
Description
Michael Burkhart
2007-03-21 10:45:12 EDT
Created attachment 61551 [details]
Picture of Scan for Updates MSAA data that is incorrect
Created attachment 61554 [details]
DefaultAction value in MSAA viewer
Created attachment 61555 [details]
Example of a good url/link DefAction value.
Are we doing this for 3.3 ? Note: if we do anything here, pls record a 3.3 patch, and a risk assessment for a 3.2.2 backport. This is UI Forms (more precisely, FormText widget). This has been a regular complaint - we should see if we can do something for 3.3 here. Thx, pls set the target accordingly. Priority lowered, could be deferred until 3.4. Chris - are you still targetting 3.3M7 ? I'm out of time in M7, this bug could take a few days as there are three separate problems in it. Will try for RC1. I have fixes for problems 2 and 3. To make it easier to follow the approvals process required for RC1 I have created a Bug 186053 to track the problems I can fix now. This bug now only tracks problem 1. Problem 1 (tab stop but no focus)is a little harder to fix than the other two. I will look into it some more since it is related to some other forms bugs relating to focus but I will fix problem 1 for Eclipse 3.3 only if I have a low risk fix. Two of the three problems (2 and 3) are resolved, see Bug 186053. I am not going to be able to fix problem 1 for RC1 and would like to defer this. Removing the target milestone. Targeting Eclipse 3.4. Reassigning my forms bugs to Adam Created attachment 75333 [details]
patch for problem 1
This patch changes the description from a Text widget to a FormText. In order to do this it was necessary to add a method to FormText that returns a String with its contents (for the purpose of Section#getDescription()). The method FormText#getAccessibleText() has been added which simply returns the result of FormTextModel#getAccessibleText().
Also modified FormText#handleFocusChange() to ensure that focus is passed to a sibling when there are no focusable items.
Michael, does this patch resolve the remaining issue for you? Dejan, can you review? Adam, adding a protected method to FormText qualifies at API. You need to add Javadoc and fully document it according to the API rules. Also remove the System.out.println from 'setDescription()'. I would have removed it myself but since you need to also add API, you should do it in the next patch. Created attachment 76164 [details] patch I misunderstood the bug before. Please disregard that last patch. :| This patch fixes the problem by adding a call to setFocusToNextSibling(...) when the FormText has no focusable segments. Since the next sibling in this case is also a FormText, this fix actually revealed a problem in which a programmatic call to FormText#setFocus() was not focusing on the first segment. This problem is fixed as well by removing code that sets FormText#mouseFocus to true for a portion of the setFocus() method. This code was added as part of a fix to bug 95612 and removing it does not cause the bug to reoccur. Additional testing on forms clients has not revealed any other regressions caused by removing the code. Committed to HEAD - that's #2 :-). Marking as FIXED. Setting milestone. This fix caused a regression. See bug 236735. For 3.5M1, the default behaviour has been changed back to allow focus without painting it. In order to work around the problem, FormText now supports the SWT.NO_FOCUS style bit which will prevent it from receiving focus in all cases. We are also considering adding support for another style bit which would cause FormText to actually render its focus. See bug 236739. |