[Bug 54068] Re: Ctrl-C / Ctrl-V copy and paste not working
I have Gentoo as well as Ubuntu on the same machine (amd64). Running it under Gnome on both. This bug manifests only on the Ubuntu side. Might be a clue - the Gentoo version builds against OpenMotif; perhaps the Ubuntu version is built against Lesstif? -- Ctrl-C / Ctrl-V copy and paste not working https://launchpad.net/bugs/54068 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 54068] Re: Ctrl-C / Ctrl-V copy and paste not working
> Looks like it could be a problem with KDE. Anyone having this problem with GNOME? Yes, I have this problem and do not have KDE installed (am running GNOME). -- Ctrl-C / Ctrl-V copy and paste not working https://launchpad.net/bugs/54068 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 54068] Ctrl-C / Ctrl-V copy and paste not working
Public bug reported: Binary package hint: nedit Current version of nedit (as of 25 July 2006). Ctrl-C does not reliably copy highlighted text to the clipboard. This bug may not manifest immediately upon nedit launch, but it shows up pretty reliably after nedit has been in use a while. The X-Windows copy/paste works normally. One possible workaround on some platforms is to replace the Ubuntu- supplied binaries for nedit and nedit-nc with the binaries downloaded from nedit.org. ** Affects: nedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Ctrl-C / Ctrl-V copy and paste not working https://launchpad.net/bugs/54068 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 51242] Re: [Bug 51242] Re: New windows shouldn't steal focus
Agreed. I personally have typed part of my password into the wrong
application window when it popped up and stole focus. Didn't end up
accidentally sending the password to someone else, fortunately, but in
principle it could have happened.
Personally I like the idea of making this a user-adjustable setting, but
I'd prefer making "strict" be the default.
On Mon, 2006-07-31 at 01:02 +, jmspeex wrote:
> Having a key in gconf is nice, but it doesn't change the fact that
> automatically giving focus to a new window (by default!) constitutes not
> only a security issue (typing a passwd in the wrong window), but a
> potential for data loss (typing "rm -rf *" in the wrong terminal). Maybe
> I should file it under "security" so it gets some attention.
>
> The security issue is very real and probably wouldn't be that hard to
> exploit remotely. Consider Alice logging on to Bob's server with ssh.
> Malicious user Mallory is already logged on the server and detects the
> attempt (seeing sshd starting with ps) and automatically sends an IM
> message to Alice ("Hi Alice, how are you?"). There is a non-zero
> probability that Alice will not see the IM window open and accidently
> type his/her password right into Mallory's IM window, giving away her
> password.
>
--
Chris Koresko <[EMAIL PROTECTED]>
Michelson Science Center, Caltech
--
New windows shouldn't steal focus
https://launchpad.net/bugs/51242
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 51242] Re: New windows shouldn't steal focus
Ah, then you are confirming the behavior I reported above. -- New windows shouldn't steal focus https://launchpad.net/bugs/51242 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 51242] Re: New windows shouldn't steal focus
This message indicates that the focus behavior for new windows should be controlled by the setting of a gconf key called /apps/metacity/general/focus_new_windows: https://lists.ubuntu.com/archives/dapper-changes/2006-April/009538.html According to the above, if one issues the command gconftool-2 --set /apps/metacity/general/focus_new_windows --type string strict then new windows won't get focus unless they appear under the mouse pointer. The long description in gconf is "This option provides additional control over how newly created windows get focus. It has two possible values; "smart" applies the user's normal focus mode, and "strict" results in windows started from a terminal not being given focus." However, on my system (Dapper, with focus_mode set to "mouse") newly- created windows always get the focus even when focus_new_windows is set to "strict"). For example, typing 'xterm' in a gnome-terminal causes an xterm to pop up, and the focus goes to the new xterm even though the mouse pointer is at the original gnome-terminal. -- New windows shouldn't steal focus https://launchpad.net/bugs/51242 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 56526] GUI apps unmount multiple partitions when one is requested
Public bug reported: When an external media device such as a USB hard disk with multiple partitions on it is connect, the partitions are mounted automatically. Right-clicking one of their icons on the Gnome desktop (Nautilus) and gives no Unmount option, but only Eject. Choosing that cause *all* the partitions on that medium to be unmounted, not just the selected one. ** Affects: Ubuntu Importance: Untriaged Status: Unconfirmed -- GUI apps unmount multiple partitions when one is requested https://launchpad.net/bugs/56526 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
Personally, I'm less concerned about the potential security issue than with the general user-interface problems the lack of strict mouse-focus produces. Examples I've experienced: * I have a data analysis package that creates about a dozen windows, at a rate of around one every 2 seconds. The focus-stealing by these output windows (which display plots of data) means that the input is effectively disabled (e.g., I can't be typing in a terminal) for an extended period of time while this happens. Ugh. * If I'm typing in some app, e.g., a text editor, and a dialog box (e.g,. a mail notification, battery status, calendar event, etc.,) pops up and gets focus, there is a strong chance that the dialog will be dismissed before I even realize it was there, let alone decide what the appropriate choice is. Oops! This is especially true since most dialogs have a default choice which is activated when the spacebar is pressed. In typical typing, every ~6th character is a spacebar. * Sometimes I want to close a bunch of windows by pointing the mouse at them and hitting Alt-F4. I've more or less given up on doing this, though, because sometimes when one window is closed, the focus switches to some window other than the one under the mouse, and if I don't notice immediately I close that window instead of the one I wanted to. Oops! * Sometimes I'm running a commandline app that generates output windows. Typically these output windows do not process keystrokes or mouse events. However, the do get the focus when they are created, so every time I create one from the terminal, I need to wave the mouse off the terminal and back onto it before I can continue working. Yuck. Generally, it's simpler and more intuitive to tell a new user, "point the mouse at a window and type into it" than "point the mouse at a window and type into it, unless a new window has been created, in which case your typing will go to that one, unless the window manager has decided not to move the focus for some reason, so really you need to wave the mouse around and then point it into the window you want to be typing into every time the window manager does something". Yes, it's sometimes convenient to have the focus go to a newly-created dialog ***which is a child of the app that currently has focus*** , but the cost of that minor convenience seems excessive if it means the focus will go to (almost) every newly-created window. Many of the Metacity themes use only subtle visual indicators of window focus, e.g., the colors of the titlebar buttons or text. This makes it especially important not to surprise the user by changing the focus without being explicitly requested to. (As it stands, I always pick window frame themes that make large, obvious changes to the titlebar and border colors to partly work around the Metacity behavior). -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 107945] Re: Security update of libx11-6 causes IDL segfault
The above workaround didn't work for me; I still get the segfault. [EMAIL PROTECTED] ~ $ ll /usr/local/rsi/lib total 948 lrwxrwxrwx 1 rootroot15 2007-05-03 11:54 libX11.so.6 -> libX11.so.6.2.0 -rw-r--r-- 1 koresko koresko 965952 2007-03-08 17:40 libX11.so.6.2.0 The relevant section of my idl script looks like this: "linux") NEW_TEXT="$BIN_DIR:$BIN_DIR/dm/lib" if [ "$LD_LIBRARY_PATH" = "" ]; then LD_LIBRARY_PATH="$NEW_TEXT" else LD_LIBRARY_PATH="$NEW_TEXT:$LD_LIBRARY_PATH" fi # Append the Sybase lib directory if Sybase set for Dataminer if [ "$SYBASE" != "" ]; then LD_LIBRARY_PATH="$SYBASE/lib:$LD_LIBRARY_PATH" fi export LD_LIBRARY_PATH # Append the Oracle lib directory if ORACLE_HOME set for Dataminer if [ "$ORACLE_HOME" != "" ]; then LD_LIBRARY_PATH="$ORACLE_HOME/lib:$LD_LIBRARY_PATH" fi if [ "$IDLJAVAB_LIB_LOCATION" != "" ]; then LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$IDLJAVAB_LIB_LOCATION:$IDLJAVAB_LIB_LOCATION/..:$IDLJAVAB_LIB_LOCATION/../native_threads" fi LD_LIBRARY_PATH=$INSTALL_DIR/lib:$LD_LIBRARY_PATH echo "The value of LD_LIBRARY_PATH is set to $LD_LIBRARY_PATH" export LD_LIBRARY_PATH ;; [EMAIL PROTECTED] ~ $ idl The value of LD_LIBRARY_PATH is set to /usr/local/rsi/lib:/usr/local/rsi/idl_6.3/bin/bin.linux.x86:/usr/local/rsi/idl_6.3/bin/bin.linux.x86/dm/lib IDL Version 6.3 (linux x86 m32). (c) 2006, Research Systems, Inc. Installation number: 16978. Licensed for use by: Jet Propulsion Laboratory IDL> plot, sin(findgen(100)) Segmentation fault (core dumped) [EMAIL PROTECTED] ~ $ -- Security update of libx11-6 causes IDL segfault https://bugs.launchpad.net/bugs/107945 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
