Created attachment 326761 [details] DebugPluginEvents 1.0 Here's an XCode project that packages a simple NPAPI plugin for testing the browser/plugin interface on OS X. This includes displaying (and logging) which events reach the plugin from the browser. The plugin displays events. It also logs events (and other information) to stdout/stderr -- where it can be seen in the Console utility or in a Terminal session (if you run the browser from there). It supports both the CoreGraphics and QuickDraw drawing models, and also both the Cocoa and QuickDraw event models. It's been tested on both Intel and PPC, on OS X 10.5 and 10.4, and in the following browsers -- FF3, FF2, Safari, Opera, Camino (1.8-branch and trunk) and an old version of OmniWeb. The project can be rebuilt on either OS X 10.4 or 10.5, and (I think) requires XCode 2.4 or higher.
Created attachment 328342 [details] [diff] [review] Patch for testing exceptions (_not_ a fix) Here's a patch that turns my DebugPluginEvents plugin into a vehicle for testing how exceptions are handled in other browsers -- particularly Safari. Since (as now written) it cripples the browser, it won't become part of the DebugPluginEvents plugin ... at least not in its present form :-) The idea is to see how browsers handle Objective-C exceptions in the plugin and in the Cocoa event loop, and to demonstrate that Safari never crashes on an Objective-C exception (or at least on ones that occur in plugins, or in the Cocoa event loop but not in "browser code"). This finding is relevant to bug 442245 and bug 340453. When an Objective-C exception occurs in Safari, the OS jumps to some kind of handler. But the handler swallows the exception, and then the OS jumps to the end of whatever try block the exception occurred in (bypassing code that would normally have executed had the exception not occurred). Safari does crash on serious, non-Objective-C exceptions -- for example dereferencing a NULL or invalid pointer, or a pointer that points to a deleted object. The exception this patch tests is in TriggerException(). The current code triggers an "invalid selector" exception (normally quite a serious error). You can (of course) change it to test other kinds of Objective-C and non-Objective-C exceptions/errors. TriggerException() is called from the plugin (from eventTypeQD(), indirectly from NPP_HandleEvent()) and from the Cocoa event loop (from [NSView keyDown:], by the magic of method swizzling). The in-plugin exception is (of course) only triggered when the plugin has the keyboard focus. The Cocoa event loop exception is only triggered when the plugin doesn't have the keyboard focus. Tests 1) Install a patched DebugEventsPlugin in /Library/Internet Plug-Ins/. 2) Run Safari and open test.html from the DebugEventsPlugin project. 3) Click in the plugin to give it the keyboard focus (the plugin background will change from gray to white). 4) Press a key and release it. You'll see the following five messages in the console: NSApplication sendEvent (before): [keyDown event] ... *** -[NSObject crud]: unrecognized selector sent to instance 0x15fa1a90 HIToolbox: ignoring exception '*** -[NSObject crud]: unrecognized selector sent to instance 0x15fa1a90' that raised inside Carbon event dispatch NSApplication sendEvent (after): [keyDown event] ... DebugEventsPlugin (0x16E89530): Type keyUp, ... Note that you don't see a "type keyDown" message from "DebugEventsPlugin". This means code execution was aborted to the end of a try block somewhere in code that specifically handles key events for plugins. (If you do this in FF3 you'll get a crash in nsObjCExceptionLogAbort().) 5) Click somewhere else on the page but outside the plugin (the plugin background will change from white to gray). 6) Press a key and release it. You'll see the following four messages in the console: NSApplication sendEvent (before): [keyDown event] ... NSView keyDown (before): ... *** -[NSObject crud]: unrecognized selector sent to instance 0x15fdc9b0 *** -[NSObject crud]: unrecognized selector sent to instance 0x15fdc9b0 Note that you don't see either an "NSApplication sendEvent (after)" or an "NSView keyDown (after)" message. This means that code execution was aborted to the end of a try block wrapping the main Cocoa event loop (usually started by a call to [NSApp run]). (I don't know why there are two "unrecognized selector" messages.) If you do this in FF3 you'll get a crash in nsObjCExceptionLogAbort(). But if you do this in a mozilla-central build as patched with my current patch for bug 442245 (attachment 327986 [review]), you'll see the following five messages: NSApplication sendEvent (before): [keyDown event] ... ChildView keyDown (before): ... *** -[NSObject crud]: unrecognized selector sent to instance 0x1c9f3270 Mozilla has caught an Obj-C exception [NSInvalidArgumentException: *** -[NSObject crud]: unrecognized selector sent to instance 0x1c9f3270] NSApplication sendEvent (after): [keyDown event] .. This shows Minefield behaving like Safari when an Objective-C exception occurs during the call to super in nsCocoaWindow_NSWindow_sendEvent: (in nsCocoaWindow.mm).
Created attachment 334707 [details] DebugPluginEvents 1.01 Minor update to include the "character code" (in addition to the "characters") when displaying and logging Cocoa-event-model keyboard events.
Created attachment 335817 [details] debugpluginevents-0.1-ko.xpi probably not a working wrapper for the plugin yet, but should be very close. untested as I haven't got time ATM. Given that the plugin is correctly installed into Fx, this extension should give you a menu item in the tools menu to open a dialog. The dialog contains the plugin with dump statements for some of the events received via *DOM*. This gives a test case of using a plugin from XUL, rather than from a browser web page, and shows the DOM events that are received prior to the plugin receiving them. These are not the same as the events received via NPAPI. See the conversation in bug 357670 for more details.
Created attachment 338379 [details] DebugPluginEvents 1.02 New version that logs (to the system console) additional information for each call to NPP_SetWindow() -- the NPWindow's coordinates and clipRect.
Created attachment 342502 [details] DebugPluginEvents 1.03 New version that logs to the system console on every update event (updateEvt for the QuickDraw event model, and NPCocoaEventDrawRect for the Cocoa event model).
Created attachment 342512 [details] DebugPluginEvents 1.04 New version that logs to the system console on every update event (updateEvt for the QuickDraw event model, and NPCocoaEventDrawRect for the Cocoa event model). Fix dumb mistake in 1.03.
Created attachment 349767 [details] DebugPluginEvents 1.05 New version that logs (to the system console) when the plugin is loaded or unloaded.
Created attachment 385262 [details] DebugPluginEvents 1.06 New version that logs additional, drawing-model-specific information on calls to NPP_SetWindow().
Created attachment 385872 [details] DebugPluginEvents 1.07 New version that (in addition to the drawing-model-specific logging added in 1.06) also (in CoreGraphics drawing mode) logs the NSWindow objects corresponding to the 'context' (a CGContextRef) and 'window' (a WindowRef object) passed to the plugin by NPP_SetWindow(). This can be used to detect when these windows don't match. See bug 500130.
Created attachment 421348 [details] DebugEventsPlugin 1.08
Created attachment 450235 [details] Add support for Cocoa Event Model text input and NPRuntime
Created attachment 487480 [details] Version 1.10: Add support for NPCocoaEventWindowFocusChanged
Marking this FIXED just to get it off my list of NEW/ASSIGNED bugs.