Services is now used in the reps bundle but can't be loaded in the json-viewer.
Since it's only used in the ObjectInspector, which we don't use in the json-viewer,
we can mock it.
MozReview-Commit-ID: DvAxzXTb67K
--HG--
extra : rebase_source : 59c907824e94825357e5049b83ba60afebeddc9a
This adds a basic StringBundle implementation using shared memory maps, but
doesn't yet hook them up to anything. They behave the same as ordinary string
bundles, but have the additional restriction that they are permanent for the
length of the session, and cannot be removed from the cache.
MozReview-Commit-ID: 4juGhhpCWPn
--HG--
extra : rebase_source : 3a9e30eeb64482056ad5c5b1fc480cf1e8333691
extra : absorb_source : e38998a347b641d4fd4243a6a1b7365543fee3c4
This class implements a shared memory key-value store that fits into a single
memory mapped segment. All of the runtime data for its instances are stored in
the shared memory region, which means that memory overhead for each instance
in each process is only a few bytes.
Importantly, the key and value strings returned by this class are also
pointers into the shared memory region, which means that once an instance is
created, its memory cannot be unmapped until process shutdown.
For the uses I intend to put it to, this is a reasonable constraint. If we
need to use it for shorter-lived maps in the future, we can add an option to
return non-literal dependent strings that will be copied if they need to be
kept alive long term.
MozReview-Commit-ID: 5BwAaDsb7HS
--HG--
extra : rebase_source : b472fe628018f88a2c4d6b3de4b7143aeca55e14
extra : absorb_source : 5cdeb568cfd2b4a5a767191402e699e61e653b3b
This class allows us to map a read-write shared memory region, and then safely
remap it read-only, so that it can be shared with sandboxed content processes.
MozReview-Commit-ID: 2PJMQgOwA4V
--HG--
extra : rebase_source : c556cabfa7d379a91dc9ef7171ac0a7d7d8fb32e
extra : absorb_source : e78e304ed95891c694050f79a0bb5d40d11ee884
The in-tree version of View MathML Source appears to have low usage, so it seems
reasonable to remove. A similar feature is available as an add-on.
In recent months, the in-tree version has actually been broken, which wasn't
noticed for quite a while. This adds further evidence for removal given the
lack of maintenance and interest in this feature.
Differential Revision: https://phabricator.services.mozilla.com/D1830
--HG--
extra : moz-landing-system : lando
Currently, in order to retrieve supported clipboard formats
DataTransfer::CacheExternalClipboardFormats repeatedly makes the same calls to
clipboard->HasDataMatchingFlavors.
In the case when aPlainTextOnly == true only 1 call is made -
clipboard->HasDataMatchingFlavors(kUnicodeMime, ...), and when
aPlainTextOnly == false we have 1 call made for every member of the list
{ kCustomTypesMime, kFileMime, kHTMLMime, kRTFMime, kURLMime, kURLDataMime,
kUnicodeMime, kPNGImageMime } - a total of 8 calls.
We can see that in nsClipboardProxy::HasDataMatchingFlavors, there is a call to
ContentChild::GetSingleton()->SendClipboardHasType.
So when aPlainTextOnly == true, we will have 1 sync message, and when
aPlainTextOnly == false, we will have 8 sync messages.
With the proposed solution, in DataTransfer::CacheExternalClipboardFormats
we will only have 1 sync message regardless of the case because
GetExternalClipboardFormats() will retrieve all supported clipboard
formats at once.
MozReview-Commit-ID: CAmBfqB459v
--HG--
extra : rebase_source : 27f1b420f2613e6a747ed63762f1583ab71ba3e0
1. Hold onto the weak callback reference inside livemarks so it
doesn't get GC'd.
2. Update other consumers of updateURIVisitedStatus to use the
string spec.
MozReview-Commit-ID: 2GOROCIJ4aA
--HG--
extra : rebase_source : e408ad53524d60f9e8ca07fa180d53b2a83dd643
Removed the code setting the channels for an rtpmap attribute in the C++ glue code.
Added Rust code that accounts the data in SdpMedia accordingly for rtpmap.
MozReview-Commit-ID: 2D5MVLJxXoh
--HG--
extra : rebase_source : ae54885e3d2cccdd04f5f758bddcf2d134f3a843
Some MSE streams will resend the same init segment. In these cases we can treat
the following data as belonging to the already existing stream. We do this by
reusing the same stream id. This stops us tearing down and restarting decoders
in these cases. This has the benefit of stopping us introducing gaps to audio
and/or video.
Differential Revision: https://phabricator.services.mozilla.com/D1837
--HG--
extra : moz-landing-system : lando
This function is practically identical to the code used to salt the profile
directory except it was fixed to not return matching strings when called in the
same second by bug 867769.
Differential Revision: https://phabricator.services.mozilla.com/D1865
--HG--
extra : moz-landing-system : lando
The .menu-iconic-right class is not used anymore so it can be removed.
MozReview-Commit-ID: 9hBGemRLB1l
--HG--
extra : rebase_source : 8a86d6cf5f244321a1eee61739878d3215ec077e
In bug 1364624 we switched over to SRWLock on Windows for our internal
implementation of mozilla::Mutex. This doesn't allow for re-entrancy. The
WebCryptoThreadPool shutdown code has potential for re-entrancy due to the
spinning of the main thread event loop while shutting down the worker threads.
By limiting the scope of the lock protecting mPool during shutdown we can avoid
the re-entrancy. Addtionally we track the shutdown status to avoid dispatching
events once shutdown has started.
--HG--
extra : rebase_source : 6e97a1fbdf4033ef93b3ecbafcf4b7898d9b19af
Disabling sandboxing seems to cause a memory regression for win32 builds which
affects our AWSY numbers. This switches over to only disabling sandboxing if
using a DMD build so that we can still run without crashing.
--HG--
extra : rebase_source : 9887c19cdd746aec9f6d9e64561f2226cd1ce443