Closed
Bug 560993
Opened 14 years ago
Closed 2 years ago
Hang: CallNPN_GetValue_NPNVnetscapeWindow IPC message not delivered? hang|mozilla::plugins::PPluginInstanceParent::CallNPP_SetWindow versus hang|KiFastSystemCallRet | NtWaitForMultipleObjects | CreateFileMappingA
Categories
(Core :: IPC, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
status1.9.2 | --- | wanted |
status1.9.1 | --- | unaffected |
People
(Reporter: benjamin, Unassigned)
References
Details
Attachments
(1 file)
2.21 KB,
patch
|
bent.mozilla
:
review+
|
Details | Diff | Splinter Review |
This hang-pair is shows up right near the top of the list, after ones jimm already fixed: browser: http://crash-stats.mozilla.com/report/index/fe46dbb4-9832-40a4-a1d4-a35ea2100418 plugin (flash and silverlight): http://crash-stats.mozilla.com/report/index/14d635f6-2c1e-4e8c-8482-467df2100418 No plugin code is really involved here. The parent is instantiating a plugin, calls NPP_SetWindow quite normally. The child does AnswerNPP_SetWindow > CreateWinlessPopupSurrogate > CallNPN_GetValue_NPNVnetscapeWindow. The browser appears never to respond to the message. I don't know whether it was sent and never received, or received and never woke up the parent main thread, or what. cjones/jimm, any thoughts?
Comment 1•14 years ago
|
||
I'm not sure what the cause is, but I can offer an alternative. We could create the surrogate parent on the fly instead of creating it for every plugin. The only time we need it is if someone right-clicks for a context menu.
Any ideas why-tf CreateFileMappingA is where it is in the child stack?
Comment 3•14 years ago
|
||
Comment 4•14 years ago
|
||
(In reply to comment #2) > Any ideas why-tf CreateFileMappingA is where it is in the child stack? Not our doing, windows must be processing something internally while we wait. or something. Wish I had the src!
Comment 5•14 years ago
|
||
Comment on attachment 440674 [details] [diff] [review] smarter use of parent surrogates v.1 Regardless of what we come up with on this, this is a good optimization that's worth adding.
Attachment #440674 -
Flags: review?(bent.mozilla)
Comment on attachment 440674 [details] [diff] [review] smarter use of parent surrogates v.1 >+ if (NPN_GetValue(NPNVnetscapeWindow, &hwnd)) { Do a != NPERR_NO_ERROR check here. >+ CreateWinlessPopupSurrogate(); I'd do this to avoid the unnecessry function call: if (!mWinlessPopupSurrogateHWND) { CreateWinlessPopupSurrogate(); NS_ASSERTION(mWinlessPopupSurrogateHWND, "fail"); }
Attachment #440674 -
Flags: review?(bent.mozilla) → review+
Reporter | ||
Comment 7•14 years ago
|
||
As much as the optimization is nice, I'm not sure it's worth taking in 3.6.4. I'm more interested in figuring out how/why the messages aren't being delivered properly.
status1.9.2:
--- → wanted
status1.9.1:
--- → unaffected
Comment hidden (spam) |
Comment 10•2 years ago
|
||
NPAPI is gone and intr
is gone and I think it's likely that whatever was going here was either fixed a long time ago, removed from the codebase, or both.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•