There can be multiple compartments within the same zone, only one of which is a
debuggee. In this scenario, CCWs from other compartments into the debuggee
compartment should be traced and treated as roots. Therefore, dealing with CCWs
at the JS::Zone level is incorrect, and this patch changes the granularity level
to JSCompartments. If you look at the callers and uses of the function, it makes
much more sense now.
Additionally, it renames `JS_TraceIncomingCCWs` to `JS::TraceIncomingCCWs`.
--HG--
rename : devtools/shared/heapsnapshot/tests/gtest/DoesCrossZoneBoundaries.cpp => devtools/shared/heapsnapshot/tests/gtest/DoesCrossCompartmentBoundaries.cpp
rename : devtools/shared/heapsnapshot/tests/gtest/DoesntCrossZoneBoundaries.cpp => devtools/shared/heapsnapshot/tests/gtest/DoesntCrossCompartmentBoundaries.cpp
We already restore the scroll-position state of the list control frame (via
nsHTMLScrollFrame), so the combobox control frame needs to add a suffix to
its state key so it doesn't overlap.
MozReview-Commit-ID: Eq0X0FCOciZ
--HG--
extra : rebase_source : 3d4b1a555f980ffaad59fbcbb72370117013812c
nsComboboxControlFrame will need some place to store its dropped-down state.
Instead of using nsISupportsPRBool and SetStateProperty, just add a bool.
MozReview-Commit-ID: CEnshCbqEV1
--HG--
extra : rebase_source : 6c4cef994ef85a1de2ff3aa40ad70bb150af9d09
nsFrameManager::CaptureFrameStateFor generates keys for stateful frames that
only take into account the document and element. This precluded saving pieces
of information coming from different frames responsible for the same element.
MozReview-Commit-ID: 29x3Gj66wAy
--HG--
extra : rebase_source : 9f6fc24ce88009b31dae9fc37bb2187cad8164f2
mDestination is cleared during unlink, which means that after that point the
window can't do much with the AudioContext, nor should need to do so.
MozReview-Commit-ID: E45aCpEfJEu
--HG--
extra : rebase_source : cafd502552b7126bcdddc2544c4c28c1b62a701f
The previous disabling of this warning on just Key.cpp was not
sufficient because another file from the unified sources list appears
to include the header exhibiting the warning.
MozReview-Commit-ID: rR2XXigTJU
--HG--
extra : rebase_source : b34b42fd729163775cdb2e4c50bb0e6099824112
The mac decoder when used on intel GPU gives bad performance due to locking. Increasing the queue size allows to alleviate most problems.
MozReview-Commit-ID: 3yQ3btiMqvk
--HG--
extra : rebase_source : 17951db2769b2cd56742ba420f08b3f5ebc2436d
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: CnmHTfEZpBK
--HG--
extra : rebase_source : acf0a7fad4efc35e7f7281023aec7056bd2049ee
This will make it easier for binaries only archive generation to consult
the list of binaries that are relevant to packaging.
This does overlap somewhat with compile databases. Perhaps someday the
logic could converge.
While I was here, I cleaned up writing of the all-tests.json file to
avoid an intermediate string variable.
This patch adds to_dict methods on some frontend data types. There is
room to improve the serialization of these types. For example, we could
use __slots__ to drive the default formatter. We could also leverage a
custom JSONEncoder class that knows how to call to_dict() on instances.
In the spirit of perfect is the enemy of done, I think this should be
deferred to a follow-up bug.
MozReview-Commit-ID: XVnKB1MNqu
--HG--
extra : source : 4167dfdf10457360c9c94ee6e55b03ef1b92c16d
extra : histedit_source : 2f3f10bbb8ef9da8c57b0d85cbf4ea80242eff1a%2C1a5654253181d75eecd5dfaca2c87e353f8126cd
Now when we print instances in a debugger, we'll see something like:
<StaticLibrary: other-licenses/snappy/libother-licenses_snappy.a>
<StaticLibrary: toolkit/library/StaticXULComponentsEnd/libStaticXULComponentsEnd.a>
<SharedLibrary: toolkit/library/XUL>
<StaticLibrary: toolkit/library/libxul_s.a>
<HostProgram: config/nsinstall_real>
<Program: memory/replace/logalloc/replay/logalloc-replay>
<SimpleProgram: mfbt/tests/TestArrayUtils>
... instead of the the class name and memory address.
MozReview-Commit-ID: 8zdrM6KfP8U
--HG--
extra : source : 84849ad026c9ba1bbf71c93172b0a03440e51bec
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, of course.
Given that the warning is in WebRTC which is third party code, there
isn't much we can do about the warning. However, Google is building
Chrome with Visual Studio 2015, so I wouldn't be surprised if this
were fixed upstream or will be fixed upstream. Then again, we allow
warnings when building WebRTC. So perhaps not.
MozReview-Commit-ID: G6JP9fkCzfn
--HG--
extra : rebase_source : bf5c9a049230bb8e483f6a85bdbc2ca20eb3ab45
This will make it easier for binaries only archive generation to consult
the list of binaries that are relevant to packaging.
This does overlap somewhat with compile databases. Perhaps someday the
logic could converge.
While I was here, I cleaned up writing of the all-tests.json file to
avoid an intermediate string variable.
This patch adds to_dict methods on some frontend data types. There is
room to improve the serialization of these types. For example, we could
use __slots__ to drive the default formatter. We could also leverage a
custom JSONEncoder class that knows how to call to_dict() on instances.
In the spirit of perfect is the enemy of done, I think this should be
deferred to a follow-up bug.
MozReview-Commit-ID: XVnKB1MNqu
--HG--
extra : rebase_source : 376c93467dde3450c7c21cff918cb34913a3c5fe
Now when we print instances in a debugger, we'll see something like:
<StaticLibrary: other-licenses/snappy/libother-licenses_snappy.a>
<StaticLibrary: toolkit/library/StaticXULComponentsEnd/libStaticXULComponentsEnd.a>
<SharedLibrary: toolkit/library/XUL>
<StaticLibrary: toolkit/library/libxul_s.a>
<HostProgram: config/nsinstall_real>
<Program: memory/replace/logalloc/replay/logalloc-replay>
<SimpleProgram: mfbt/tests/TestArrayUtils>
... instead of the the class name and memory address.
MozReview-Commit-ID: 8zdrM6KfP8U
--HG--
extra : rebase_source : 7f964ad44a0061674f77d5716a6769a4aedb9e6c
While almost identical to video/mp4, quicktime files often use codecs that we don't support: in particular MPEG4 part 2 and amr audio.
If a plugin exists and is enabled, prefer it to handle those files.
We only do so when opening the file directly. Media in <video> element will always play natively.
MozReview-Commit-ID: 1yPpzfDaCfT
--HG--
extra : rebase_source : 4c66eb0fd81a288f4c8eed643c79cf9851bd4273