If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Simple NPAPI plugin for testing browser/plugin interactions on OS X

RESOLVED FIXED

Status

()

Core
Plug-ins
RESOLVED FIXED
9 years ago
3 years ago

People

(Reporter: smichaud, Assigned: smichaud)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 10 obsolete attachments)

8.21 KB, patch
Details | Diff | Splinter Review
2.75 KB, application/octet-stream
Details
186.30 KB, application/zip
Details
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.
(Assignee)

Updated

9 years ago
Assignee: nobody → smichaud
(Assignee)

Comment 1

9 years ago
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).
(Assignee)

Comment 2

9 years ago
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.
Attachment #326761 - Attachment is obsolete: true

Comment 3

9 years ago
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.
(Assignee)

Comment 4

9 years ago
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.
Attachment #334707 - Attachment is obsolete: true
(Assignee)

Comment 5

9 years ago
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).
Attachment #338379 - Attachment is obsolete: true
(Assignee)

Comment 6

9 years ago
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.
Attachment #342502 - Attachment is obsolete: true
(Assignee)

Comment 7

9 years ago
Created attachment 349767 [details]
DebugPluginEvents 1.05

New version that logs (to the system console) when the plugin is
loaded or unloaded.
Attachment #342512 - Attachment is obsolete: true
(Assignee)

Comment 8

8 years ago
Created attachment 385262 [details]
DebugPluginEvents 1.06

New version that logs additional, drawing-model-specific information
on calls to NPP_SetWindow().
Attachment #349767 - Attachment is obsolete: true
(Assignee)

Comment 9

8 years ago
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.
Attachment #385262 - Attachment is obsolete: true
Created attachment 421348 [details]
DebugEventsPlugin 1.08
Attachment #385872 - Attachment is obsolete: true
(Assignee)

Updated

8 years ago
Attachment #421348 - Attachment description: Fix problems with support for Cocoa NPAPI → DebugEventsPlugin 1.08
Created attachment 450235 [details]
Add support for Cocoa Event Model text input and NPRuntime
Attachment #421348 - Attachment is obsolete: true
Created attachment 487480 [details]
Version 1.10:  Add support for NPCocoaEventWindowFocusChanged
Attachment #450235 - Attachment is obsolete: true
Marking this FIXED just to get it off my list of NEW/ASSIGNED bugs.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.