Closed Bug 293813 Opened 20 years ago Closed 17 years ago

Camino updates Java applets on every keystroke (too often)

Categories

(Camino Graveyard :: Plug-ins, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME
Camino2.0

People

(Reporter: smichaud, Unassigned)

References

()

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050415 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050427 Camino/0.8.4 When using the OJI Plugin interface (at least), Camino triggers two separate updates for every keystroke that occurs when the focus is in a Java applet. This can cause the applet to flash annoyingly on every keystroke. I'm not able to test any other kind of plugin, but I suspect that Camino behaves this way for every kind of OJI plugin, and perhaps for every kind of plugin altogether. It's possible for plugins to work around this problem (by squelching unnecessary updates). But that shouldn't really be required. I'm the author of the Java Embedding Plugin (http://javaplugin.sourceforge.net/). My current version (0.9.1) contains a workaround for what I've been calling the Camino "spurious updates" problem (i.e. it squelches the unnecessary updates, as best it can). And it can be configured to output information to the Java Console that demonstrates what I'm reporting here. To turn on this kind of debug tracing in the Java Embedding Plugin, add the following "Java Runtime Parameter": -Djep.debug.updates=true Then you'll see that for every keystroke (not including arrow keys), Camino makes a call to nsIPluginInstance::SetWindow() and posts an update event (calls PostEvent() with an "EventKind" of "updateEvt", or somehow causes this to happen). This doesn't happen with Firefox (1.0.3) or Mozilla (1.7.7). I tested with Camino 0.8.4 and with the latest Camino nightly (2005-05-10-14). Reproducible: Always
-> simon
Assignee: pinkerton → sfraser_bugs
Target Milestone: --- → Camino0.9
Do you have a stack trace for the update?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
The stack is showing that we redrawing the plugin, which means that it got invalidated on the keydown (is this expected?). It seems that the real issue isthat we call SetWindow() every time we paint, though that's probably in there to get RealPlayer to display correctly.
Here they are. I'm not sure how much good they'll do you -- they both seem to be spawned by [NSWindow displayIfNeeded]. But if you follow the instructions I've given, you can demonstrate for yourself that a call to setWindow() and an updateEvt occur every time you press a key while a text input field inside a Java applet has the focus. (To say "whenever an applet has the focus" seems, after all, to be imprecise/incorrect.) To get these (and to make sure I had the right ones), I altered the source code of MRJPlugin.plugin and JavaEmbeddingPlugin.bundle in the following way: I inserted empty calls to setWindowBreak() and updateEvtBreak() at the appropriate places in MRJContext.cp, and I inserted an empty call to keyDownBreak() in a "handler" for [NSApplication sendEvent], which I used poseAsClass to "hook". That way I could see that the extra setWindow() and updateEvt "events" did take place just after a key down, and that I was generating traces for the right ones. (I used gdb, of course, to set breakpoints at those "empty calls".)
> which means that it got invalidated on the keydown (is this > expected?). I certainly didn't expect it, and don't think it should be considered correct (or normal) behavior. It doesn't happen in Firefox or Mozilla. > It seems that the real issue is that we call SetWindow() every time > we paint, though that's probably in there to get RealPlayer to > display correctly. Groan :-) The Java Embedding Plugin has now been changed to deal with this problem ... though I've already had one bug report about a problem that might be due to how I implemented my workaround. But if RealPlayer needs this behavior, I can probably keep revising my workaround until I get it right. On the other hand, it'd be nice to get rid of some or all of my (hackish) workaround, if it turns out that RealPlayer (or something else) _doesn't_ really need this behavior.
> It seems that the real issue is that we call SetWindow() every time > we paint No. A spurious updateEvt is just as harmful as a spurious call to SetWindow(): An updateEvt can't tell you to update only part of an object, so (if you decide to pay any attention to it) you've got to update the whole thing. Just like with SetWindow(). Yes, I suppose just one of them is better than having both, but there's nothing to choose between them, as far as I can tell. Better still to have _no_ screen updates be tied to every keystroke.
So can we find out where the invalidate is coming from?
I have no idea myself. And I'm not (currently) in a particularly good position to find out: I don't yet know much about the Camino-specific code. And since I've got a workaround for this problem (though it's a bit creaky), and a lot of other JEP-related things on my plate, I'm not likely to start playing the code-detective with Camino for a while. In a few months I may have time to get back to this issue. In the meantime, though, maybe someone else can take a crack at it. Maybe someone on the Mozilla.org Mac programmer team. Maybe someone whose initials are JA :-)
It does seem to be related (thanks for pointing it out) ... but only in a general way: Bug 184755 isn't Camino-specific, and is about the (apparently excessive) number of updates that occur while scrolling. This bug is Camino-specific, and is about updates that occur on every keystroke. I tried scrolling the example given in bug 184755 (http://www.lohn1.de/lobn.htm), and it _is_ very slow with Java 1.3.1 (using either Apple's Java Applet.plugin or my MRJ Plugin JEP), but it isn't so bad with Java 1.4.X or 1.5 (using my JavaEmbeddingPlugin.bundle). The reason must be that JavaEmbeddingPlugin.bundle suspends screen updates while the browser window is scrolling or changing size. By the way, it's been in the MRJ Plugin that I've been implementing my workaround for this bug (bug 293813), so it turns out I've also been addressing some of Simon's issues (in bug 184755).
Target Milestone: Camino0.9 → Camino1.0
The patch from bug 298961 may have changed things here so that SetWindow is only called when the clip rect changes.
Target Milestone: Camino1.0 → Camino1.1
Yes, the per-keystroke call to SetWindow is gone, and its disappearance does coincide with the fix for bug 298961 (landed on the trunk on 2005-09-28, and on the branch two days later). The per-keystroke updateEvt is still there, though. But this particular case of the (general) spurious updates problem is no longer a problem for the Java Embedding Plugin -- my workarounds eliminate the its effects on the JEP, and seem to be quite stable.
(In reply to comment #13) > The per-keystroke updateEvt is still there, though. Surely this is expected (as long as you are typing in a text field), since inputting text will invalidate some region of the text field, so that the new text gets redrawn?
Yes, but a plugin has no way of knowing that the update is for only part of its display, so it has to assume that the whole display needs updating. There isn't any per-keystroke updateEvt in Firefox. I think that's the correct behavior. (I actually tried getting an "update region" for the Carbon WindowRef in the MRJ Plugin's handler for updateEvts -- but that only works in a Carbon event handler, when you're handling a kEventWindowUpdate event.)
Assignee: sfraser_bugs → nobody
Status: ASSIGNED → NEW
QA Contact: plugins
Target Milestone: Camino1.1 → Camino2.0
What's the state of this in trunk? I would guess that this is either fixed, or should live in Cocoa Widgets now.
This now seems older than the dinosaurs :-) There may still be underlying issues, but I'm not aware of any that have any ill effect on the Java Embedding Plugin. I'm marking this WFM. If others still see similar issues, they should open new bugs.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
> There may still be underlying issues, but I'm not aware of any that > have any ill effect on the Java Embedding Plugin. Trunk and branches.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: