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)
Tracking
(blocking2.0 beta7+)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta7+ |
People
(Reporter: jaas, Assigned: jaas)
Details
Attachments
(2 files)
(deleted),
patch
|
cjones
:
review+
benjamin
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
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.
Comment 5•14 years ago
|
||
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.
Fixes comment.
Attachment #477386 -
Attachment is obsolete: true
Attachment #477386 -
Attachment is obsolete: false
pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/9c48c74c8c4a
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•