Bug 457686 - [VirtualBox] Some Ctrl key combinations do nothing or the wrong thing
[VirtualBox] Some Ctrl key combinations do nothing or the wrong thing
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-03 12:19 EDT by Robin Green
Modified: 2008-09-01 04:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-01 04:46:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robin Green 2008-08-03 12:19:11 EDT
In impress, Ctrl+S toggles underlining, instead of saving, and Ctrl+A doesn't appear to do anything. Ctrl+Z works as expected, however.

Version-Release number of selected component (if applicable):
openoffice.org-impress-3.0.0-0.0.28.1.fc10.i386

How reproducible:
Always

Steps to Reproduce:
1. Create a new document in ooimpress
2. Press CTRL+S
  
Actual results:
Document is not saved (underline is enabled if you are editing text, though)

Expected results:
Document should be saved

Additional info:
rawhide is running within VirtualBox OSE 1.6.2 on Mac OS X 10.5.
Comment 1 Caolan McNamara 2008-08-03 12:27:40 EDT
This works perfectly fine for me with a "normal" rawhide. Are the short-cuts for Ctrl+S listed beside "save" in the file menu, and Ctrl+A listed beside select all in the edit menu, and does e.g. gedit work correctly. Assuming here that everything is in English in OOo etc.
Comment 2 Robin Green 2008-08-05 07:05:33 EDT
(In reply to comment #1)
> This works perfectly fine for me with a "normal" rawhide. Are the short-cuts
> for Ctrl+S listed beside "save" in the file menu

yes

> and Ctrl+A listed beside
> select all in the edit menu

yes

> and does e.g. gedit work correctly.

yes

> Assuming here
> that everything is in English in OOo etc.

yes

The bug also occurs if I run ooimpress as a different user (which I've never used to run openoffice.org before).
Comment 3 Caolan McNamara 2008-08-05 07:21:58 EDT
Its still a fairly abnormal setup, I'd guess that the keymap is somehow screwed up, but e.g. if ctrl+s is underlining instead of saving, and ctrl+s is listed as doing save, then I'd almost expect that typing "s" gives a u. 

I guess you could use xev to check the status of e.g. ctrl+s as seen by a raw application
Comment 4 Robin Green 2008-08-05 07:52:19 EDT
(In reply to comment #3)
> Its still a fairly abnormal setup, I'd guess that the keymap is somehow screwed
> up, but e.g. if ctrl+s is underlining instead of saving, and ctrl+s is listed
> as doing save, then I'd almost expect that typing "s" gives a u. 

No, it gives an 's'.

> I guess you could use xev to check the status of e.g. ctrl+s as seen by a raw
> application

I couldn't figure out how to hook xev up to the openoffice window. As I said, gedit works correctly. So I ran xev with no arguments and this is what it gave me for Ctrl+S:

KeyPress event, serial 31, synthetic NO, window 0x4000001,
    root 0x5c, subw 0x0, time 21642575, (95,101), root:(360,126),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:                                      
    XmbLookupString gives 0 bytes:                                    
    XFilterEvent returns: False                                       

KeyPress event, serial 31, synthetic NO, window 0x4000001,
    root 0x5c, subw 0x0, time 21642656, (95,101), root:(360,126),
    state 0x4, keycode 39 (keysym 0x73, s), same_screen YES,     
    XLookupString gives 1 bytes: (13) ""                         
    XmbLookupString gives 1 bytes: (13) ""                       
    XFilterEvent returns: False                                  

KeyRelease event, serial 31, synthetic NO, window 0x4000001,
    root 0x5c, subw 0x0, time 21642779, (95,101), root:(360,126),
    state 0x4, keycode 39 (keysym 0x73, s), same_screen YES,     
    XLookupString gives 1 bytes: (13) ""                         
    XFilterEvent returns: False                                  

KeyRelease event, serial 31, synthetic NO, window 0x4000001,
    root 0x5c, subw 0x0, time 21642793, (95,101), root:(360,126),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:                                      
    XFilterEvent returns: False                                       


I forgot to mention - I'm also using KDE 4.1.
Comment 5 Caolan McNamara 2008-08-05 08:17:47 EDT
No idea really, there was some weirdness in X with keyboards recently but that should have worked through at this stage.
Comment 6 Robin Green 2008-08-05 10:36:09 EDT
FYI, I tried exporting DISPLAY to the DISPLAY of Apple's X server on the Mac OS X host, and running ooimpress on that, and still had this problem.
Comment 7 Caolan McNamara 2008-08-12 03:15:06 EDT
I'll have to just give up on this unless there is any route to reproduce this that I can follow :-(
Comment 8 Caolan McNamara 2008-09-01 04:46:34 EDT
Just to see if it would happen in Virtual Box, I gave a quick attempt to install the Alpha-10 release VirtualBox running under F-9, and the Alpha release kernel just dies, so didn't get any further.

Note You need to log in before you can comment on or make changes to this bug.