This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 409423 - Setting clientArea disabled in WorkbenchWindow#run(..) still allows typing in Editor
Summary: Setting clientArea disabled in WorkbenchWindow#run(..) still allows typing in...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.3   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 4.4 M1   Edit
Assignee: Eric Moffatt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 380258 (view as bug list)
Depends on:
Blocks: 414142
  Show dependency tree
 
Reported: 2013-05-29 14:43 EDT by Paul Webster CLA
Modified: 2018-05-13 15:15 EDT (History)
7 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Webster CLA 2013-05-29 14:43:51 EDT 
From Bug 409274

As part of fixing bug 404016, we disable disableControl(tpl.clientArea, toEnable); and that should disable all typing in the views and editors.

Despite the ancestor of the editor StyledText being disabled, we were still able to type into the editor.

PW
Comment 1 Eric Moffatt CLA 2013-05-29 16:03:36 EDT 
OK, after a few hours with Car and Silenio we've found the problem. The contributedPartRenderer was overriding the 'setFocus' handling and the implementation was returning 'true' where it shouldn't.

I reality that composite shouldn't even have been asked because its parent was already disabled but that's a separate SWT defect.

I've pushed the fix(es) to Gerrit:

https://git.eclipse.org/r/13370

This fixes the typing issue by explicitly checking whether the composite itself is enabled before trying to put the focus on the widget.

I've also fixed the bogus id for the StatusBar so that the disabling of the bottom trim controls now actually takes place.

NOTE: There is still a slight issue; if you use the Search bar to execute the 'Quick Hierarchy' command you can still type into the search field. This is evidently a known SWT defect on windows...
Comment 2 Markus Keller CLA 2013-05-29 18:06:12 EDT 
In WorkbenchWindow#run(..), when the
    if (statusLine != null && statusLine.getWidget() instanceof Control)
ends up false, then the whole
        for (Control bottomCtrl : tpl.bottom.getChildren())
loop is skipped.

Shouldn't the for-loop be moved out of the if-body?
Comment 3 Eric Moffatt CLA 2013-05-30 09:14:53 EDT 
Markus, I'd thought of that but decided to minimize the changes...
Comment 4 Eric Moffatt CLA 2013-06-06 11:28:13 EDT 
*** Bug 380258 has been marked as a duplicate of this bug. ***
Comment 5 Markus Keller CLA 2013-07-18 07:00:15 EDT 
(In reply to comment #1)
> OK, after a few hours with Car and Silenio we've found the problem. The
> contributedPartRenderer was overriding the 'setFocus' handling and the
> implementation was returning 'true' where it shouldn't.
> 
> I reality that composite shouldn't even have been asked because its parent
> was already disabled but that's a separate SWT defect.

I couldn't find an SWT bug for this.
Comment 6 Eric Moffatt CLA 2013-07-31 10:23:43 EDT 
Committed (to master):

http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c8c18df706581cb68bf34de22c81fa6c4b585808

This is a rework of the original Gerrit that also includes Markus' suggestion of eliminating the check around the 'for' loop.
Comment 7 Paul Webster CLA 2013-08-01 10:02:28 EDT 
.
Comment 8 Daniel Rolka CLA 2013-08-07 09:30:17 EDT 
Verified in the build: I20130805-2000
Comment 9 Eclipse Genie CLA 2018-05-13 15:15:28 EDT 
New Gerrit change created: https://git.eclipse.org/r/122544