Still, I concur with NoOp in this bug should no longer be in UNCONFIRMED state, since it clearly is not an individual case. However, after that I've reopened one more time SeaMonkey, everything has worked right in Mail and Browser and it still works OK. In the Error Console I haven't noticed any message that sounded related to drag and drop problems. I've closed and reopened SeaMonkey about 8 times with Mail as the initial only component, and the issue has reproduced every time, both using SM 2.10 and SM 2.12a2. I can confirm it also in SeaMonkey 2.10 final and 2.10a2, using Mageia 1 (Gnome 2.32.1, Linux kernel 2.6.38). However, I do notice the the cursor _briefly_ changes to a D&D cursor when I drag it from 'Inbox' to message title. I cannot replicate if I fall back to SeaMonkey 2.9.1 (same machine, same profile). I can ssh into the machine when it is in this state, but cannot find anything in the dmesg or Xorg.0 logs that changes when I replicate this. At that point the cursor immediately changes to a D&D. I can replicate by opening a -mail -browser & immediately going to the mail window, selecting 'Inbox' on any one of my email accounts (POP3 or IMAP) and moving the cursor to a message to select. Once the application has been killed, the mouse returns to a normal cursor & I again have complete control. The only way that I can regain control of the cursor is open a new terminal (Ctrl-Alt-t) or drop to a vt (Ctrl-Alt-F1 thru 6) and use 'killall seamonkey'. Keyboard, including function keys, works fine. However clicking any mouse button, or rotating scroll wheel makes no difference at all. The cursor changes to a Drag & Drop cursor, I can move the cursor around (including outside of SeaMonkey. It's like it got stuck waiting to pick up a "drag item" that doesn't exist?īuild identifier: Mozilla/5.0 (X11 Linux x86_64 rv:13.0) Sometimes it's good for a while, other times I hit this in quick succession. So, I've hit this 6 times since ~/.xsession-errors has been reset, not counting another several times when running from the console where the GTK error was originally observed.Įven the frequency of occurrence is inconsistent: $ grep -c 'IA_gtk_clipboard_get_for_display' ~/.xsession-errors (firefox:7870): Gtk-CRITICAL **: IA_gtk_clipboard_get_for_display: assertion `!display->closed' failed Usually end up resorting to changing to a virtual terminal and killing firefox: Interestingly, the keyboard still works in Firefox, although browsing with an effectively disabled mouse is a real challenge. +, and perhaps other window manager keyboard shortcuts, does not work. Attempts to abort the false "drag" (ESC, trying to actually drag and drop something, changing vts, etc) do not work. Sometimes (not always), the current tab will move to a new window and the cursor remains a drag cursor even afterward. Moving the mouse around - with no buttons depressed - the mouse cursor occasionally will change into a drag cursor. Tried searching for likely phrases and didn't find a likely match. Sincerely hope this is a duplicate of a bug with a pending patch.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |