Closed Bug 598223 Opened 14 years ago Closed 14 years ago

more gracefully handle Carbon plugins that are forced out of process

Categories

(Core Graveyard :: Plug-ins, defect)

All
macOS
defect
Not set
normal

Tracking

(blocking2.0 beta7+)

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: jaas, Assigned: jaas)

Details

Attachments

(2 files)

Carbon plugins (Silverlight being a prime example) crash when forced out of process because we don't support them out of process. We force all plugins out of process by default in x86_64 builds. We should probably more gracefully handle this situation.
Attached patch fix v1.0 (deleted) — Splinter Review
Attachment #477386 - Flags: review?(jones.chris.g)
With this patch Silverlight instances just behave like Silverlight isn't installed. Much better than the disruption caused by crashing and in many cases it leads to the default install UI which can trigger a user to upgrade to a plugin that works.
Comment on attachment 477386 [details] [diff] [review] fix v1.0 Two technical points: first, it would be nice to somehow log why we rejected a particular plugin, but I can't think of anything nice here. Maybe just a printf? Second, it seems wasteful to keep around a useless plugin subprocess, but without a better error notification I guess there's not much we can do. It'd be nice to have the plugin process commit suicide and then blacklist it somehow. That aside, this is OK by me both technically and politically for beta7 with a followup filed for notification and blacklisting, but I don't know what our policy is re Carbon plugins on 10.6. Roping in bsmedberg, who might know something I don't. I guess this isn't much worse than before we had mixed-architecture support; we're just losing the "can't find plugin for MIME type" doorhanger.
Attachment #477386 - Flags: review?(jones.chris.g)
Attachment #477386 - Flags: review?(benjamin)
Attachment #477386 - Flags: review+
Just because a plugin negotiates Carbon for one instance doesn't mean it always will, so we don't want to blacklist it just because it did that. Flash and Quicktime are both known to negotiate different drawing models for different instances and in some very rare cases different event models including Carbon.
blocking2.0: --- → beta7+
Comment on attachment 477386 [details] [diff] [review] fix v1.0 "actively negotiation" should be "actively negotiate". Is there a way to tell plugins that we only support certain modes (e.g. only windowless on android/maemo, only cocoa on mac, etc)?
Attachment #477386 - Flags: review?(benjamin) → review+
(In reply to comment #5) > Is there a way to tell plugins that we only support certain modes (e.g. only > windowless on android/maemo, only cocoa on mac, etc)? Plugins can query for mode support but there is a default mode on each architecture, without negotiation the default mode will be selected.
Attached patch fix v1.1 (deleted) — Splinter Review
Fixes comment.
Attachment #477386 - Attachment is obsolete: true
Attachment #477386 - Attachment is obsolete: false
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: