Closed
Bug 344150
Opened 18 years ago
Closed 9 years ago
Window activation problems when using JEP
Categories
(Plugins Graveyard :: Java (Java Embedding Plugin), defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: mark, Unassigned)
References
Details
When using JEP, there are problems with window activation. Carbon events for activation and deactivation can be sent multiple times (somewhat tolerable) or not at all (trouble). I see this on all branches. This was somewhat changed by JEP version F, but there's still something up. The information below was collected from a current trunk build with JEP F. From bug 344006 comment 3: -- Open two windows, window 1 and window 2 Activate window 1 and load Java applet therein Click on window 2, observe events: win1 deactivate win2 activate win2 activate (again) Click on window 1, observe events: win1 activate win1 activate (again) Click on window 2, observe events: win1 deactivate win2 activate Click on window 1, observe event: win1 activate Subsequent clicks on either window produce the same results as the last two clicks listed above. The clicks above are in the window's content areas. Things change slightly when the clicks are on the title bars: the first two clicks above are the same, but last two clicks above double up on events: Click on window 2 title bar, observe events: win1 deactivate win1 deactivate (again) win2 activate win2 activate (again) Click on window 1 title bar, observe events: win1 activate win1 activate (again) When using command-` to switch windows, things behave slightly better in that activation and deactivation events are reliably sent to the windows. The window that contains the applet does see more than one event on activation change, though, and it'll also see additional activate events whenever the command key is pressed. -- There is a patch at attachment 228701 [details] [diff] [review] that provides a workaround by introducing new paranoia on the browser side. If possible, this should be fixed on the JEP side.
Comment 1•18 years ago
|
||
This could be the JEP's fault. Or it might be caused by yet more bugs in Apple's Cocoa-Carbon interface (ones I haven't yet discovered and worked around). I will look into this. But I'll put it behind bug 344006 (TSM doc issues) and bug 344153 (missing kEventRawKeyDown and kEventRawKeyUp events), because those seem to be more urgent.
Reporter | ||
Comment 2•18 years ago
|
||
*** Bug 338642 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 3•18 years ago
|
||
It would still be nice to fix this in the JEP if it's possible, but we've now got a workaround in widget for other reasons. Attachment 228701 [details] [diff] from bug 344006 has been checked in.
Comment 4•18 years ago
|
||
I've been working on this now, off and on, for several months. It's a real beast (_much_ more complicated than I first realized). Even so, JEP 0.9.6 would have contained a fix (a comprehensive one as far as I can tell), except that I noticed problems with Firefox 1.5.0.X and SeaMonkey 1.0.X, which forced me to disable my fix. The fix (though disabled) is still in my (new) source code. You'll find most of it by searching on 344150 in Handlers.m (my comments also contain a description of the problems I found). Fortunately it's easy for Mozilla.org browsers to work around this problem. (For JEP 0.9.6 see bug 364158.)
Assignee: nobody → smichaud
Component: Java: OJI → Java Embedding Plugin
QA Contact: nobody → java.jep
Component: Java Embedding Plugin → Java (Java Embedding Plugin)
Product: Core → Plugins
Version: 1.8 Branch → unspecified
Comment 5•9 years ago
|
||
The JEP is long gone.
Assignee: smichaud → nobody
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•8 years ago
|
Product: Plugins → Plugins Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•