Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 346390

Summary:

Ctrl+A (select all) is not applied to the (right) focused area

Product:

[Eclipse Project] e4

Reporter:

John <M8R-sgiphk>

Component:

Assignee:

Eric Moffatt <emoffatt>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

gheorghe, pwebster, remy.suen

Version:

unspecified

Flags:

remy.suen: review+

Target Milestone:

4.1 RC4

Hardware:

OS:

Windows 7

See Also:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=323706
https://bugs.eclipse.org/bugs/show_bug.cgi?id=538981

Whiteboard:

Attachments:

Description	Flags
Option 1 - search field has a context v01	none
Option 2 - search field uses the Focus service v01	none
Option 2 - search field uses the Focus service v02a	none

Description John

2011-05-19 04:20:01 EDT

Build Identifier: I20110518-2200

it might be same as this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=323706
that is, if that one gets fixed maybe this one will too. But check this first:
Basically Ctrl+A should select the text in the current text area but it doesn't, instead something unfocused in another window gets selected.

Reproducible: Always

Steps to Reproduce:
1. get a detached Problems view, ie. Window->Show View->Problems, right click on its title tab and Detached (ok this doesn't exist in e4? it's only Close, then I don't know how you detach it in e4 but since I already used settings and workspace from a 3.7 eclipse it remained detached)
2. make sure Errors and/or Warnings have children and they are expanded (at least 1 child should be visible, else if none expanded this won't work)
3. click inside the editor (inside a java file) OR click on a file in Package Explorer (Ctrl+A will have effect here)
4. click in Problems view directly on any child (or even the parent)
5. now click on Window->Preferences, you should be focused on the Filter text , you can enter some text(preferably) and/or just press Ctrl+A there, this won't select the entered text, this will in fact apply Ctrl+A in the editor, or in package explorer (depending which one was last focused before you clicked on a child in Problems View)

Comment 1 Remy Suen

2011-05-19 06:34:51 EDT

(In reply to comment #0)
> 1. get a detached Problems view, ie. Window->Show View->Problems, right click
> on its title tab and Detached (ok this doesn't exist in e4? it's only Close,
> then I don't know how you detach it in e4 but since I already used settings and
> workspace from a 3.7 eclipse it remained detached)

Right now you'd have to resize your main window so it doesn't take up all the space and then click and drag the part outside the main window's area to detach it.

Comment 2 John

2011-05-20 11:03:01 EDT

this also happens (in e4) when you activate the Quick Access  ie. Ctrl+3 or just click on it, then type something(or not) and press Ctrl+A, it selects all code in my editor window (in a .java file) assuming of course that was the last one focused

Comment 3 John

2011-05-27 05:47:23 EDT

more importantly, this also happens in the Commit Changes window of Team->Commit for git, ie. shift+delete for cut (which doesn't cut the text, only copies it) and shift+insert which will paste that text as new snippet (since my previous focused window was package explorer and the project root on which I clicked Team->Commit).
Workaround is LMB click the Commit Message edit area and it works as expected

Comment 4 Paul Webster

2011-05-30 11:22:02 EDT

In 3.x we had to provide extra global source providers to support attaching handler to a trim control so that it could override the default workbench behaviour.  See bug 177806 and bug 154268

In Eclipse 4 the architecturally correct solution would look like creating an IEclipseContext for that control and making it the active child of the Window context while that control is active.  But that effects which handlers are enabled/disabled, what is the active part, and I'm not sure what that does to the available commands listed in the quick assist dropdown.



PW

Comment 5 Paul Webster

2011-05-31 12:15:47 EDT

Created attachment 196998 [details]
Option 1 - search field has a context v01

The search field gets its own context.  It's activated when the text field gets focus.  It provides handlers for the cut/copy/paste/select all

This needs to be refined a little to handle all different SWT event combinations.

PW

Comment 6 Paul Webster

2011-05-31 12:28:34 EDT

Created attachment 197000 [details]
Option 2 - search field uses the Focus service v01

This uses the focus service and a handler expression to track the focus control.

It is 3.x API, and it does not work.

PW

Comment 7 Paul Webster

2011-05-31 13:36:23 EDT

Created attachment 197011 [details]
Option 2 - search field uses the Focus service v02a

Option 2 that works.  Uses the IFocusService API.  Fixes a bug in the handler lookup function in the legacy handler service bridge.

PW

Comment 8 Paul Webster

2011-05-31 13:36:48 EDT

Remy, can you have a look at Option 2?

PW

Comment 9 Remy Suen

2011-05-31 13:51:15 EDT

(In reply to comment #8)
> Remy, can you have a look at Option 2?

Patch looks okay. 'Home' and 'End' does nothing if your active part is a text editor though.

Comment 10 Remy Suen

2011-05-31 14:15:10 EDT

(In reply to comment #9)
> 'Home' and 'End' does nothing if your active part is a text
> editor though.

Since this is not a regression, let's get the patch in for now to fix Ctrl+A at least.

Comment 11 Paul Webster

2011-05-31 14:16:48 EDT

Released to HEAD
PW

Comment 12 Eric Moffatt

2011-06-06 09:58:29 EDT

Verified in I20110604-2201

Remy, for me the home/end keys work as long as the Quick Access doesn't have focus...