(2/211) 2533 - partial focus capture on (alt|cmd)-tab task switching

Logged In: YES
user_id=1509906

Same behaviour with jedit 4.2 final and 4.3pre3, on sun jDK 1.4 and 5

Logged In: YES
user_id=1079067

I get this issue too. jEdit gets focus but text areas don't get full focus. Can
sometimes happen when you dismiss a dialog.

Using Apple JDK 1.5 & 1.4.2. (Sun does not provide one for Mac OS X).

Logged In: YES
user_id=2029469
Originator: NO

I see the same problem many times per day, although I cannot find a way to reliably produce the failure.

Many things besides the arrow keys do not work while in this state, including keyboard shortcuts for Copy and Save. For example, Apple-S types an "s" in the document, rather than doing Save. The (silent) failure of Copy is particularly annoying, since I then paste into some other app with whatever random thing was alread in the copy buffer.

The failure state ends when you type into a document.

I"m using jEdit version 4.2pre12, Java 1.5.0_13, under Leopard. The problem has existed for a long time however, e.g. under Tiger too.

Logged In: YES
user_id=2029469
Originator: NO

I have not explored "docked" windows at all, so I'm pretty sure I do not have any "docked" plugins. The plugins I have showing in Plugin Manager are:

Editor Scheme
Jakarta Commons
Latest Version Check
Mac OS Plugin
QuickNotepad

Regards,
Patrick

Logged In: YES
user_id=2029469
Originator: NO

I'd like to broaden the description of the "hung" text area state somewhat. The ignored keystrokes include back-space, delete, home, end, page-up, and page-down (in addition to the arrow keys, and all keyboard shortcuts previously mentioned).

Also, if I have two buffers in a "split view", I can move the focus (blinking cursor) between them via the menu item View:Splitting:Go To Next Text Area without clearing the failed state. The only thing that clears it is a normal letter/number key stroke.

Regards,
Patrick

Logged In: YES
user_id=802617
Originator: NO

As far as I am concerned, it might be related to bugs 1242430, 1527334, 1609548, 1650718, 1721208 and 1747202... All those items are related to keyboard keys randomly not functionning properly.

Matthieu tried a fix between 4.3pre12 and 4.3pre13 (revision r11222) that I have used for a few weeks, and I have not been able to reproduce the bug anymore (it used to happen quite often). As I had not found a reliable way of reproducing the bug (some combinations of alt+tab triggered the bug, but not always), I wanted to use the new release a bit before saying "It's ok", but I must admit the bug seems to be gone once and for all.

For me, it is a big THANK YOU to Matthieu for getting rid of that most particularly annoying bug.

For all who have met those keyboard bugs, have you tried the latest relase ?

Logged In: YES
user_id=2029469
Originator: NO

Alas, I've tried 4.3pre13 for about a week on Java 1.5.0_13 under OS-X version 10.5.2 and have seen no improvement to this keyboard problem. I'm glad it's working for you though. :)

Patrick

My symptoms are a bit different than original bug description, but I posted here since causes seem similar.


\*\*\*\*\*Description\*\*\*\*\*
If JEdit gets called by xdvi to do dvi reverse search through latex source specials, it loses keyboard focus, i.e. JEdit window is focused but normal text typing (i.e. MOST keystrokes) doesn't work (except for Return key which creates a new line, or Ctr+Home which gets to buffer start, and maybe a few other odd combinations) and cursor does not show on current line (which is marked in color as usual, anyway) until you do one of the following:

-click on the text area
-Press TAB
-Press Ctrl-TAB (which in KDE is by default not available)


\*\*\*\*\*Workaround\*\*\*\*\*
Call jedit with the command line parameter -run=/usr/local/share/bug.bsh, where bug.bsh looks like this:

void doSomethingUseful()
{
void run()
{
// view = jEdit.getLastView();


//prova=jEdit.newFile(view);
//jEdit._closeBuffer(view,prova);

view.splitVertically();
view.unsplitCurrent();


}

if(jEdit.getLastView() == null)
VFSManager.runInAWTThread(this);
else
run();
}

doSomethingUseful();


(written taking inspiration from jedit builtin help faq)

\*\*\*\*\*Considerations.\*\*\*\*\*
Maybe this has to do with the way xdvi calls its editor, as stated on xdvi manpage (http://linux.die.net/man/1/xdvi):
"The argument of this option isn't executed as a shell command, but via exec() to prevent evil tricks with the contents of source specials."

Maybe this is a general java fault, as the following links could let suppose:

http://groups.google.com/group/comp.lang.java.gui/browse_thread/thread/360927e294780b28
http://forums.sun.com/thread.jspa?threadID=5163401&tstart=0

I remember that on JWM window manager things were still worse, the misbehaviour showing even when window-switching via Alt+Tab. I have not the chance of test it right now.

This is obviously an annoying bug.


\*\*\*\*\*Test software versions.\*\*\*\*\*
Operating System: Linux slax 2.6.24.5
Jedit 4.3 pre 15

java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)

xdvi 22.84.9 (motif)

fluxbox 1.0.0
KDE 3.5.9

Still occurs in jEdit 5.1.0 server-background mode, using Apple Inc. Java 1.6.0_65 on OSX 10.9.3

I could not find the option for "simplified keyboard handling"

The only thing I seem to have docked is the File Browser, which I think was there by default. The only plugin that appears in Plugin Manager is "Plugin Central Default", but Plugin Options has options for QuickNotepad. Docking shows Activity Log (floating), File Browser (left), HyperSearch Results (floating), Markers (floating), QuickNotepad (floating), Registers (floating), Task Monitor (floating).

The only customizations I recall making are to the default encoding and encodings on the menu (re bug #3869), and possibly to the wrap margin.

Has this bug really received no attention in 6 years? I assume the developers use jEdit constantly, do you not see this on your computers? What OS & Java version are you using that doesn't have this problem?

Simplified Keyboard Handling no longer exists in jEdit - it was removed before jEdit 4.5 was released.
I removed all the comments about it since they just confuse the readers.
I am unable to reproduce this on Linux anymore, so I removed my comment about that.

There are some times when jEdit has a weird focus state but I need step-by-step instructions on how to reproduce it in order for me to address the issue. Perhaps this is a mac osx only issue?

Anyway, when I do find I need to refocus my textarea, I use the "scroll and center caret" action which also has the side-effect of focusing my textarea properly. I use this so often I don't even think about it these days since i often have a dockable with keyboard focus and I need to go back to the textarea without using my mouse.

- **labels**: keyboard / shortcuts --> keyboard / shortcuts, MacOSX specific

I've never seen this problem and can't reproduce it, but I don't have a Mac, so I'm thinking this is a Mac specific issue. Arch Linux with current updates, OpenJDK 1.8.

Hadn't opened jEdit on Mac in years, updated to the latest version today and tried to reproduce the error. Most of the time it works as expexcted, but just now I switched back to it and got the opposite problem: the arrows worked, but letters didn't, until after I clicked. "jEdit 5.5.0 server-background mode, using Oracle Corporation Java 1.8.0_172" on macOS 10.13.6 (17G2112)