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

Bug 366542

Summary: Go to last edit location broken on Mac
Product: [ECD] Orion Reporter: John Arthorne <john.arthorne>
Component: EditorAssignee: Project Inbox <orion.editor-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: eclipse.felipe, susan
Version: 0.4   
Target Milestone: 0.4 M2   
Hardware: Macintosh   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:

Description John Arthorne CLA 2011-12-13 09:17:58 EST
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?)
Comment 1 Susan McCourt CLA 2011-12-13 11:38:46 EST
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....
Comment 2 Susan McCourt CLA 2011-12-13 12:00:57 EST
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...
Comment 3 Susan McCourt CLA 2011-12-13 12:24:40 EST
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?
Comment 4 Felipe Heidrich CLA 2011-12-13 12:29:51 EST
(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?)
Comment 5 Susan McCourt CLA 2011-12-13 14:22:56 EST
(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).
Comment 6 Felipe Heidrich CLA 2011-12-15 11:50:25 EST
(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.
Comment 7 Susan McCourt CLA 2011-12-15 13:39:24 EST
I am seeing the problem on Safari 5.1
Comment 8 Felipe Heidrich CLA 2011-12-15 16:23:39 EST
(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 ?
Comment 9 Susan McCourt CLA 2011-12-16 13:23:45 EST
(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?
Comment 10 Felipe Heidrich CLA 2011-12-16 13:37:18 EST
(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.
Comment 11 John Arthorne CLA 2011-12-16 16:31:58 EST
(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.
Comment 12 John Arthorne CLA 2012-02-06 15:07:21 EST
This was fixed.