Bug 292055 - [KeyBindings] Search menu accelerator key not present if on startup opens a non-java resource
Summary: [KeyBindings] Search menu accelerator key not present if on startup opens a n...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows XP
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-12 11:46 EDT by work CLA
Modified: 2019-09-06 16:03 EDT (History)
0 users

See Also:


Attachments
my key bindings as requested (23.29 KB, text/plain)
2009-10-13 12:33 EDT, work CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description work CLA 2009-10-12 11:46:43 EDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: 20090621-0832

Normally, in order to open the Search menu in Windows you can press Alt-A, the a of the Search menu option is underlined.

However, if you configure eclipse to reopen your workspace automatically and re-open previously open files and make sure that the file you were editing just before closing eclipse was a non-java file like a pom.xml file then the Search menu does not have the a underlined.

This bug has been present on at least the last 2 versions of eclipse before this one, I have opened a bug before which someone closed saying they could not reproduce, it is *always* reproducable on my machine so if you cannot reproduce let me know and I will experiment around finding the minimum requirement.

Workaround is to make a java file the current file and restart.


Reproducible: Always

Steps to Reproduce:
1. Setup eclipse to auto-open workspace and auto-load any previously open files
2. Make sure you are in the java perspective
3. Open some files, make a pom.xml file your currently viewed/editing file
4. Exit and restart eclipse, the Search menu will not be accessible from the keyboard any more
Comment 1 Paul Webster CLA 2009-10-13 09:14:02 EDT
What happens if you use ALT+A ... is it a currently active keybinding in your pom.xml file?

PW
Comment 2 Paul Webster CLA 2009-10-13 09:28:21 EDT
You can also use CTRL+SHIFT+L from the now-open editor to see if that key is in use.

PW
Comment 3 work CLA 2009-10-13 09:43:20 EDT
Just been playing around trying to reproduce this consistently and the original description is slightly wrong.
You need to go to the Team Synchronizing view and select a pom.xml file as your currently viewed/edited file.
Then shutdown/restart and the Alt+A of the menu is gone.
If you select a .java file and restart then the Alt+A of menu is present (via the Team Synchronizing view).

Fyi, I am using svn, subclipse from tigris.org, not sure if that is relevent or not.

Re key bindings, Ctrl+Shift+L doesn't show any binding for Alt+A.
Under Windows/Prefs, Alt+A is bound to Terminal View Insert (which I didn't do on purpose).
Comment 4 Paul Webster CLA 2009-10-13 10:35:00 EDT
Could you go to the Keys preference page and change that ALT+A keybinding to something else (ALT+F12 for example).   Then repeat your usecase.

I suspect that an ALT+A keybinding is active when you bring it up in this state.  Eclipse will always favour the keybinding over the menu accelerator (which is why you don't see the a underlined in Search).

PW
Comment 5 work CLA 2009-10-13 10:49:56 EDT
Removed Alt+A key binding from Windows/Prefs Keys page, made no difference.
Comment 6 Paul Webster CLA 2009-10-13 11:24:55 EDT
(In reply to comment #5)
> Removed Alt+A key binding from Windows/Prefs Keys page, made no difference.

Please export your keybindings from the Keys pref page>Export CSV and attach it to the bug.

PW
Comment 7 work CLA 2009-10-13 12:33:33 EDT
Created attachment 149452 [details]
my key bindings as requested
Comment 8 Eclipse Webmaster CLA 2019-09-06 16:03:47 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.