PublishTarget calls Unlock on our LiveSetAutolock.
It's possible for GetInitialInterceptorForIID to fail after this point.
This will cause the failure cleanup code to run, which tries to call Unlock again.
However, the previous call to Unlock set mLiveSet to null, and Unlock previously didn't handle this case.
Now, unlock is a no-op (in release builds) if it's already been called.
MozReview-Commit-ID: 15ffXR6nKqc
--HG--
extra : rebase_source : bf072824f15f5574dd8afbedef82b795086d5fff
If GetInitialInterceptorForIID fails, the live set lock is not released in most cases, but the newly created Interceptor will be destroyed.
The Interceptor's destructor tries to acquire the live set lock again, but that causes a deadlock, since reentry is no longer allowed for a mutex after bug 1364624.
GetInitialInterceptorForIID now ensures the live set lock is always released on failure, thus preventing the deadlock.
MozReview-Commit-ID: z0Q7JLnJXQ
--HG--
extra : amend_source : 0b9837e5500754b5782e72337fc59b7904c5e29c
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
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
This replaces some old Chromium code that tries to minimally disentangle
an arbitrary file descriptor mapping with simpler algorithm, for several
reasons:
1. Do something appropriate when a file descriptor is mapped to the same
fd number in the child; currently they're ignored, which means they'll
be closed if they were close-on-exec. This implementation duplicates
the fd twice in that case, which seems to be uncommon in practice; this
isn't maximally efficient but avoids special-case code.
2. Make this more generally applicable; the previous design is
specialized for arbitrary code running between fork and exec, but we
also want to use this on OS X with posix_spawn, which exposes a very
limited set of operations.
3. Avoid the use of C++ standard library iterators in async signal safe
code; the Chromium developers mention that this is a potential problem in
some debugging implementations that take locks.
4. In general the algorithm is simpler and should be more "obviously
correct"; more concretely, it should get complete coverage just by being
run normally in a debug build.
As a convenient side benefit, CloseSuperfluousFds now takes an arbitrary
predicate for which fds to leave open, which means it can be used in
other code that needs it without creating a fake fd mapping.
MozReview-Commit-ID: EoiRttrbrKL
--HG--
extra : rebase_source : 336e0ba9f56dc80f7347dc62617b4ad1efea7e7e
This directory has a number of places where files unintentionally depend
on `#include`s and `using` directives and forward declarations in other
files in the same unified build group. Adding a file shifts the group
boundaries and exposes some of those bugs; this patch fixes them (but
there are others).
MozReview-Commit-ID: AqAOdnXniTn
--HG--
extra : rebase_source : ed6030785d9cc5cc0ea1a46707725472de1c0fa9
We were first allocating and mapping a virtual memory area using mach_vm_allocate
(similar to mmap with MAP_ANON) and then obtaining a shareable capability for the
underlying VM object using mach_make_memory_entry_64. However the memory mapping
is fragmented into multiple objects if it's over 128mb. Larger memory allocations
than 128mb weren't possible. To fix this, we are calling mach_make_memory_entry_64
with MAP_MEM_NAMED_CREATE. That will create a new memory object and return a port
for it.
MozReview-Commit-ID: 5LLiaqJx175
--HG--
extra : rebase_source : 7ac964a1093eaf8ee30f319f5d21132c5d884362
This function returns the transform value modified by both OMTA and APZC.
Note that the transform conversion code is almost the same as the code dropped
in https://hg.mozilla.org/mozilla-central/rev/415811f3804f .
MozReview-Commit-ID: HmsMQp3O4n4
--HG--
extra : rebase_source : ac3994359d646dedaa5ff2f664b20787be8a75f6
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This defines three flushing functions that flush different parts of the
WR pipeline. Using all three guarantees that everything sent to WR will
have been flushed. This is what we need to do in SyncWithCompositor to
ensure that it meets the API contract.
In addition, this patch updates the existing FlushRendering function to
use the new functions (no functional changes intended here).
MozReview-Commit-ID: GzxwpF4JT04
--HG--
extra : rebase_source : 1a8cf434d1280902906da257ae63751da7ffd114
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
This adds all the samples from the provided sample set to the CountHistogram's
storage, instead of just adding 1 sample of value 1. This change does not affect
code outside of GeckoView persistence since |AddSampleSet| is not used in other
places.
MozReview-Commit-ID: 9bE0M9dgrtE
--HG--
extra : rebase_source : c2147d084415518b02148daa83107045f2993c0f
