Community
Participate
Working Groups
Many of the widgets in the Forms library (Section, BusyIndicator, FormHeading) will accept keyboard focus even though they can't do anything with it. The impact is that when someone calls setFocus on a Form that contains a FormHeading at its top (which is quite common), keyboard focus ends up nowhere. Looking at the patterns in SWT, it appears that the correct protocol is for controls to return false from setFocus if they can't do anything with the focus so that the caller can try assigning focus somewhere else.
Created attachment 49575 [details] Patch that fixes the problem This patch fixes the problem by overriding forceFocus() to return false in all subclasses of Composite that can't do anything with focus directly, but might have children that can. This appears to fix the problem for me, but someone should probably consult with Steve Northover to ensure that this is a valid reason for overloading forceFocus. Another possible solution may be to set the NO_FOCUS flag whenever one of these classes is instantiated, but this wouldn't catch places where they are instantiated in 3rd-party code.
Will this change affect context sensitive help at all? If the dynamic help view is open it determines the help context from the control that has focus and does this whenever a part activation event is generated (such as when a view gains focus). Are there any situations where this patch would change the behavior so that a control which would have had focus no longer does so? If so we should look at whether that is going tocause any existing views to not show the right context help.
The patch should only affect widgets that don't accept any form of user input (such as labels, titles, progress bars, etc)... and it should not affect part activation in any way. The only way this would change the initial focus within a part would be if the initial focus had been going to a control that couldn't accept it. The part would open with no visible cursor, no widget showing the affordance for keyboard focus, and the user would be unable to type anywhere until they click on something or hit tab. Since this would be a bug, it is unlikely that anyone would be relying on it to correctly compute their help contexts.
While seeing users might prefer to have the focus in the first editable control, a blind user would like the screenreader to read the sections title and description first. Maybe there should be a workbench-wide option for such issues.
I have no disagreement that screen readers should read the text in the order it appears, however the screen reader should not be relying on keyboard focus in order to determine what text to read. Keyboard focus is intended for determining where input goes, not where output comes from. A screen reader that could not read text unless it has keyboard focus would be quite badly broken already.
Patch applied. Note: Instead of overriding forceFocus on Section, I did it on ExpandableComposite (a Section is an ExpandableComposite). Also, I omitted the SWT.NO_FOCUS flag on the Text widget because: - It is not a valid flag for a Text widget. I also cannot subclass Text, so I see no straightforward way to prevent focus from going to it. - You actually can do something with focus.. you get a cursor and can select text and copy it to the clipboard. Not that useful, but still, not useless either.
Had to roll back this fix in M6 as it surfaced a new problem, bug 178704, which we don't have time to fix in M6. Will re-apply after M6.
Created attachment 61695 [details] patch for when we re-apply
Not enough time to review and test this for M7.
I believe the patch is safe to apply. It tested well for me. The issue reported in bug 178704 will no longer occur with this patch due to the fix for bug 178821.
Created attachment 84331 [details] resynched patch The patch had conflicts when I tried to pull it in. Here is the up-to-date version.
Fixed in HEAD.
