This was in a previously reviewed patch. I dropped the change because I
thought the underlying warning had been fixed. I was wrong.
MozReview-Commit-ID: J9B34YhJ3z0
--HG--
extra : source : ea446df75d17331a7c0736ef3303bf9a07d8d9f0
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists on fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: BgLmpUa09c6
--HG--
extra : rebase_source : bee12f3e67aca3bfd320ee729ea6213dc48576b8
I also add some missing data to the content version, namely the duration of time that ContentParent::SendLoadPlugin takes.
MozReview-Commit-ID: 8qSZopvY1D7
--HG--
extra : rebase_source : ca717c149a52ed1ece9ac0678dca0c284ab26c5d
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: Gcq3Qna02iB
--HG--
extra : rebase_source : 2ccaa22eb85280cc8d322df87fb759e8dff67cf1
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
--HG--
extra : rebase_source : 166b913b401582c6948e4b61efc102dc1b9c8d2f
When turned on e10s, plugin process creates from chrome process. So content
process doesn't know current sandbox level. To rewrite wmode attribute on
contnet process by sandbox level >= 2, we should store sandbox level to
nsPluginTag.
MozReview-Commit-ID: DCQ5g7uCbJF
--HG--
extra : rebase_source : 7064f469e873ea1301e28faeab0bbb27613978db
These are unused. PPluginScriptableObject uses its own Variant type
for IPC. Furthermore, there is a bug in ParamTraits<NPString>::Read
that ends up copying out uninitialized memory.
Experience shows that we do not have enough profiler labels to make
BHR hang reports meaningful. This patch adds enough labels to let us
exploit hang reports matching the 25 topmost chrome hangs.
--HG--
extra : rebase_source : b9ec379c58255a250db1020377147c95c82df712
Experience shows that we do not have enough profiler labels to make
BHR hang reports meaningful. This patch adds enough labels to let us
exploit hang reports matching the 25 topmost chrome hangs.
--HG--
extra : rebase_source : b9ec379c58255a250db1020377147c95c82df712
This patch:
- Makes the following substitutions (plus necessary namespace qualifiers:
gfxImageFormat::ARGB32 --> SurfaceFormat::A8R8G8B8_UINT32
gfxImageFormat::RGB24 --> SurfaceFormat::X8R8G8B8_UINT32
gfxImageFormat::A8 --> SurfaceFormat::A8
gfxImageFormat::RGB16_565 --> SurfaceFormat::R5G6B5_UINT16
gfxImageFormat::Unknown --> SurfaceFormat::UNKNOWN
- Changes gfxImageFormat to be a typedef to gfx::SurfaceFormat. This will be
removed soon.
- Removes gfxCairoFormatToImageFormat() and gfxImageFormatToCairoFormat() and
replace calls to them with CairoFormatToGfxFormat() and
GfxFormatToCairoFormat().
- Removes ParamTraits<gfxImageFormat>.
- Add namespace qualifiers to SurfaceFormat instances where necessary.
--HG--
extra : rebase_source : f56e92b1593957a9e4e00171100bc7605816e696