Closed
Bug 1127374
Opened 9 years ago
Closed 9 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•9 years ago
|
||
![]() |
Assignee | |
Comment 2•9 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•9 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•9 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•9 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•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f106104d8fd7
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Updated•1 year ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•