Commit Graph

21 Commits

Author SHA1 Message Date
Nicholas Nethercote
e20e423748 Bug 1352575 (part 5) - Remove PluginModuleParent::mIsStartingAsync. r=jimm.
This allows a bunch of other things to be removed too, including
PluginModuleParent::mSurrogateInstances,
PluginModuleChromeParent::sInstantiated, and NS_PLUGIN_INIT_PENDING.

The patch also removes the AsyncPluginInit crash annotation.
2017-04-18 16:56:43 +10:00
Cervantes Yu
b2491ab85e Bug 1360308 - Part 2: Use callback in CrashReporterHost::GenerateMinidumpAndPair() and up the caller chain. r=gsvelto
This changes CrashReporterHost::GenerateMinidumpAndPair() and up the caller chain to use callbacks so we
may call it synchronously or asynchronously.

MozReview-Commit-ID: 4PQH6cVdOk0
2017-06-22 18:52:58 +08:00
Peter Van der Beken
664ad944ee Bug 558184 - Part 6 - Return fake plugins in e10s too. r=bz. 2015-05-21 15:15:08 +02:00
Andrew McCreight
8f66878a7c Bug 1333915, part 2 - Stop using bridges and spawns in plugins. r=jimm
The old code would do the content process portion of the open by
immediately sending a message back to the content process, but this
has some weird issues with nesting and priorities. Instead of doing
that, I return the endpoint for the content process back to the
original sync call. This requires more code changes, to thread the
endpoint along, but it is conceptually simpler.

Once I removed the bridges and got it working, I was just able to
remove the spawns from the IPDL file and it worked.

MozReview-Commit-ID: 1tfiJrV4jbV
2017-01-25 14:17:17 -08:00
Gabriele Svelto
f8555cd1cf Bug 1262852 - Create a minidump of the plugin process as soon as possible during hang r=jimm 2016-06-24 14:25:08 +02:00
Gabriele Svelto
f8f593accf Backed out changeset c1dd7376263e (bug 1262852) which caused crashdumps from plugin hangs to be without a signature. 2016-06-12 00:25:25 +02:00
Gabriele Svelto
55058521bf Bug 1262852 - Create a minidump upon each plugin hang r=jimm 2016-05-26 00:14:36 +02:00
Aaron Klotz
aa93454d29 Bug 1161169: Clean up usage of mContentParent and clearly identify it as specifically for async plugin init; r=billm,jimm
mContentParent is really just to be used while handling a synchronous
ContentParent::RecvLoadPlugin call when async plugin init turned on.

In any other context, using it will be unsafe.

This patch adds comments and assertions to ensure that this value isn't set
otherwise, and converts the one use of mContentParent outside of async plugin
init to use an alternative mechanism for identifying the content process.

MozReview-Commit-ID: Esgt1kj0MCt
2016-03-03 00:24:36 -07:00
Jim Mathies
970fa22aae Bug 1190364 - "With electrolysis (e10s) enabled and lots of tabs open, plugincheck often fails to find any plugins". r=billm 2015-11-11 05:35:00 +01:00
Birunthan Mohanathas
a29151dc87 Bug 1182996 - Fix and add missing namespace comments. rs=ehsan
The bulk of this commit was generated by running:

  run-clang-tidy.py \
    -checks='-*,llvm-namespace-comment' \
    -header-filter=^/.../mozilla-central/.* \
    -fix
2015-07-13 08:25:42 -07:00
Jim Mathies
dd9333e112 Bug 1178998 - Identify which hang detector reports a hang. r=billm 2015-07-06 12:39:25 -05:00
Jim Mathies
536efcfe2d Bug 1160142 - For e10s plugin hangs take the minidump of the browser process before we message the chrome UI about the hang. r=billm 2015-06-11 12:25:45 -05:00
Mike Conley
65a98b8305 Bug 1148012 - Add a run ID for plugins to differentiate subsequent runs of the same plugins. r=jimm.
Normally, this could be served by the process ID of a plugin, however, run ID is meant
to be consumed by multi-process browser chrome code for telling different runs of a
plugin apart (for example, for searching the DOM for a crashed instance of a plugin,
while ensuring that we don't accidentally find newly spawned instances that have not
crashed). Exposing something as low-level as the process ID to browser chrome code
seemed like Too Much Information. Also, there is the extremely unlikely chance that
a process ID might be re-used immediately after the original process shuts down. This
run ID avoids that case, regardless of how unlikely.
2015-03-17 13:42:34 -04:00
Jim Mathies
c393878aed Bug 1127374 - Make ContentParent::RecvLoadPlugin less failure prone. r=billm 2015-01-30 10:37:03 -06:00
Bill McCloskey
6fd30079d3 Bug 1118618 - [e10s] Slow script/plugin hang UI (r=mrbkap,mconley,bent) 2015-01-16 18:34:47 -08:00
Bill McCloskey
2b46bc434f Backout bug 1118618 on a CLOSED TREE 2015-01-16 14:46:05 -08:00
Aaron Klotz
6bf78c5f34 Bug 1117244: Prevent e10s plugin module bridging from preempting async init messages; r=jimm 2015-01-16 14:03:27 -07:00
Bill McCloskey
b1608c4471 Bug 1118618 - [e10s] Slow script/plugin hang UI (r=mrbkap,mconley) 2015-01-16 10:11:18 -08:00
Carsten "Tomcat" Book
142af71e50 Backed out changeset 8ab6c26d26f5 (bug 1118618) 2015-01-13 08:43:32 +01:00
Bill McCloskey
bc51ef7890 Bug 1118618 - [e10s] Slow script/plugin hang UI (r=mrbkap,mconley) 2015-01-12 23:06:54 -08:00
Bill McCloskey
7061e6eaa0 Bug 641685 - Start plugins from the chrome process in e10s (r=bsmedberg)
This patch has a few side effects:
1. Plugins in the chrome process are "mirrored" to all content processes,
although this mirroring is currently imperfect (bug 1090576)
2. Plugins are no longer sorted by modification date in nsPluginHost.
3. Plugin exceptions are no longer propagated to JS code. They are ignored.
2014-10-29 08:05:36 -07:00