Community
Participate
Working Groups
0.4 M1 running on orionhub.org The new "Last Edit Location" command is bound to Ctrl+Q on Windows. This would translate to Cmd+Q on the Mac, except Cmd+Q is reserved for closing the application on Mac. If you open Key Assist, it lists the key binding for "Last Edit Location" is simply "Q", but this isn't working either. Clearly we are getting overridden by higher powers here and need to pick a different binding on Mac (maybe same as what we use on desktop?)
What I've observed is that we are typically able to override browser bindings (not that we want to) and sometimes the default behavior will happen, too, if our code didn't stop the event from bubbling. The fact that it's not showing Cmd+Q in the key assist is interesting....
The keybinding is setup to check for the Mac and use modifier 4 (Ctrl) when on a Mac. One bug is that the util method that makes user readable strings out of keybindings wasn't showing the 4th modifier key, so the key assist was showing "Q" on mac instead of "Ctrl+Q". I fixed that (locally) but the binding itself is still not working...
Reassigning to the editor guys for a look. My fix (which will cause the key assist to show "Ctrl+Q" instead of "Q" is not released yet but this is cosmetic only. I debugged this a little bit, and indeed on the Mac the binding is triggered for "Ctrl+Q". However, just before the binding is triggered, a model changed event is fired as if a character was inserted, so the code that goes to the last edit location stays on the current line. So the question is...why is a model changed event firing on the Mac when the user invokes Ctrl+Q?
(In reply to comment #3) > So the question is...why is a model changed event firing on the Mac when the > user invokes Ctrl+Q? unexpected, do you have the stack ? (In Eclipse, on Mac, what is the keybinding for Last Edit Location?)
(In reply to comment #4) > (In reply to comment #3) > > So the question is...why is a model changed event firing on the Mac when the > > user invokes Ctrl+Q? > > unexpected, do you have the stack ? Not handy, sorry. But you can put a breakpoint at editorFeatures line 444 to watch it trigger. It was a one character change at the cursor location where I triggered Ctrl+Q. (Incidentally I have released my part of this fix so that now when you open the key assist panel you will see Ctrl+Q as the binding).
(In reply to comment #5) > > unexpected, do you have the stack ? > > Not handy, sorry. But you can put a breakpoint at editorFeatures line 444 to > watch it trigger. works for me (event not triggered), tested on chrome and firefox on orion.eclipse.org using Ctrl+Q shortcut.
I am seeing the problem on Safari 5.1
(In reply to comment #7) > I am seeing the problem on Safari 5.1 fixed, thank you Susan http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=4182598ed23d8380255fa0a64408b3aa2dbe99a7 note that Ctrl+q wont always work on Safari, sometimes the browser sends the event with the keycode set to 229 instead of 0x51. close the bug as fixed ?
(In reply to comment #8) > note that Ctrl+q wont always work on Safari, sometimes the browser sends the > event with the keycode set to 229 instead of 0x51. > > close the bug as fixed ? sure. If we know when the "sometimes" is that it won't work, it would be worth documenting. John, do we have a readme/known issues list anywhere?
(In reply to comment #9) > (In reply to comment #8) > > > note that Ctrl+q wont always work on Safari, sometimes the browser sends the > > event with the keycode set to 229 instead of 0x51. > > > > close the bug as fixed ? > > sure. If we know when the "sometimes" is that it won't work, it would be worth > documenting. John, do we have a readme/known issues list anywhere? not 100% in a sequence of: Down Control Down q Up q Down q Up q Up Control usually the first down q is bad and second is good.
(In reply to comment #9) > sure. If we know when the "sometimes" is that it won't work, it would be worth > documenting. John, do we have a readme/known issues list anywhere? We don't currently have such a document as far as I know. Is this a browser bug? If so, and since Safari isn't one of our supported browsers it doesn't seem worth calling it out.
This was fixed.
