Closed
Bug 1127374
Opened 10 years ago
Closed 10 years ago
Make ContentParent::RecvLoadPlugin less failure prone
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(e10sm5+)
RESOLVED
FIXED
mozilla38
Tracking | Status | |
---|---|---|
e10s | m5+ | --- |
People
(Reporter: jimm, Assigned: jimm)
References
Details
Attachments
(1 file, 1 obsolete file)
9.60 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
#1 top KillHard cause (see parent bug)
mozilla::dom::PContentChild::SendLoadPlugin(unsigned int const &)
http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#978
Assignee | ||
Comment 1•10 years ago
|
||
Assignee | ||
Comment 2•10 years ago
|
||
This should eliminate the open question of whether or not SendLoadPlugin failures happen in plugin library initialization code. The other possibility would be that the auto-generated protocol code fails for some reason.
Attachment #8556666 -
Attachment is obsolete: true
Attachment #8556719 -
Flags: review?(wmccloskey)
Comment on attachment 8556719 [details] [diff] [review]
patch
Review of attachment 8556719 [details] [diff] [review]:
-----------------------------------------------------------------
::: dom/plugins/ipc/PluginModuleParent.cpp
@@ +91,5 @@
> static void ReleaseCallee(Class* obj) { }
> };
>
> bool
> mozilla::plugins::SetupBridge(uint32_t aPluginId,
It's kinda weird that this returns two kinds of failure conditions. Do we actually want to treat a failure in ::Bridge differently? How about having it return an nsresult and then converting the result from ::Bridge to an nsresult?
Attachment #8556719 -
Flags: review?(wmccloskey) → review+
Assignee | ||
Comment 4•10 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #3)
> Comment on attachment 8556719 [details] [diff] [review]
> patch
>
> Review of attachment 8556719 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> ::: dom/plugins/ipc/PluginModuleParent.cpp
> @@ +91,5 @@
> > static void ReleaseCallee(Class* obj) { }
> > };
> >
> > bool
> > mozilla::plugins::SetupBridge(uint32_t aPluginId,
>
> It's kinda weird that this returns two kinds of failure conditions. Do we
> actually want to treat a failure in ::Bridge differently? How about having
> it return an nsresult and then converting the result from ::Bridge to an
> nsresult?
Isn't PPluginModule::Bridge auto-generated code? Looks like it's created here -
https://dxr.mozilla.org/mozilla-central/source/dom/plugins/ipc/PPluginModule.ipdl#37
Assignee | ||
Comment 5•10 years ago
|
||
will land an additional touchup if we decide on something.
https://hg.mozilla.org/integration/mozilla-inbound/rev/f106104d8fd7
Sorry, by "it" I meant SetupBridge. So something like this:
if (!PPluginModule::Bridge(...)) {
return NS_ERROR_UNEXPECTED;
}
return NS_OK;
Assignee | ||
Comment 7•10 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #6)
> Sorry, by "it" I meant SetupBridge. So something like this:
>
> if (!PPluginModule::Bridge(...)) {
> return NS_ERROR_UNEXPECTED;
> }
> return NS_OK;
I'd like to keep the current fix in place for the weekend so that we can get a feel for whether a majority of the the failures are in the auto-generated PPluginModule code or the plugin code. Sound ok?
Comment 8•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•