Replace mozilla.widget.use-argb-visuals pref by -moz-gtk-csd-transparent-background media query at browser.css
to draw transparent background. The media query is set by toolkit code and enabled when compatible
window manager is detected.
Differential Revision: https://phabricator.services.mozilla.com/D6658
--HG--
extra : moz-landing-system : lando
Add the first version of the IPDL-JS API, which allow chrome JS to load IPDL files and use them to communicate accross Content processes.
See IPDLProtocol.h for more information regarding how to use the API.
Differential Revision: https://phabricator.services.mozilla.com/D2116
--HG--
rename : ipc/moz.build => ipc/ipdl_new/moz.build
extra : moz-landing-system : lando
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
This removes the rarely used and somewhat odd
`iterator& BeginWriting/EndWriting(iterator&)` functions that take an iterator
as an in/out param and then return it.
--HG--
extra : rebase_source : 92066f996595e9b7df9642813c08592cee47c630
This switches over the few remaining usages of the deprecated
BeginWriting/EndWriting(iterator&) functions to the more standard
BeginWriting/EndWriting() functions.
--HG--
extra : rebase_source : 3c54621d4921eb45157ec4edce0b693bdd7f02d5
As in Bug 1390583 and Bug 1470993, this will correct them to be external symbols
Differential Revision: https://phabricator.services.mozilla.com/D6044
--HG--
extra : moz-landing-system : lando
This adds a most recently used cache that can be used as a quick lookup table
for frequently used entries.
--HG--
extra : rebase_source : 571c32f75e985e299113f73b959809d208aad5f3
XPCOM strings mark logically unused parts of nsStringBuffer as uninitialized
in debug builds by writing a marker byte and if memory checking is active,
by telling the memory checking that the range of memory is uninitialized.
This patch limits such marking to up to 16 code units to avoid quadratic
behavior, which is especially bad when there's a large disparity between
length and capacity (after a call to SetCapacity()).
The assumption here is that even a small poisoned memory range is enough
to detect the bugs that the poisoning is intended to detect.
MozReview-Commit-ID: 178rp0ckztj
Differential Revision: https://phabricator.services.mozilla.com/D5838
--HG--
extra : moz-landing-system : lando
clang can handle MSVC-like codepaths generally, so we want to use those
when building with clang for Windows. So we switch _MSC_VER over to _WIN32
to pick up those codepaths when compiling for Windows with clang.
Additionally, we relax the ordering of sections for the same scenario.
Note that we do need to tell clang to use -fms-extensions with the MSVC code,
we do that in the mingw clang build job patch.
Differential Revision: https://phabricator.services.mozilla.com/D3526
--HG--
extra : moz-landing-system : lando
> dom/media/gmp/CDMStorageIdProvider.cpp(63,10): warning:
> local variable 'storageId' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClip.cpp(581,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClipChain.cpp(88,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/nsDisplayList.cpp(179,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> gfx/thebes/gfxWindowsPlatform.cpp(454,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Will remove std::move().
> gfx/thebes/gfxFontEntry.cpp(245,20): warning:
> local variable 'name' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> netwerk/cookie/nsCookieService.cpp(4460,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
GetPathFromURI() result is stored in an nsAutoCString, so it might as well return that type.
> toolkit/components/extensions/WebExtensionPolicy.cpp(462,12): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
> toolkit/components/extensions/WebExtensionPolicy.cpp(475,10): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
`result` may be empty or may be arbitrarily long, so I'll use nsCString inside the function.
> toolkit/xre/CmdLineAndEnvUtils.h(349,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Returning an UniquePtr, will remove std::move().
Also will `return s` instead of `return nullptr` when `(!s)`, to avoid extra construction which could also prevent elision (not entirely sure, but it's at least not worse!); and it's clearer that the two `return`s return the same already-constructed on-stack object.
> tools/profiler/core/shared-libraries-win32.cc(111,10): warning:
> local variable 'version' will be copied despite being returned by name [-Wreturn-std-move]
nsPrintfCString -> nsCString, will add std::move().
> xpcom/glue/FileUtils.cpp(179,10): warning:
> local variable 'fullName' will be copied despite being returned by name [-Wreturn-std-move]
> xpcom/glue/FileUtils.cpp(209,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
nsAuto{,C}String -> ns{,C}String, will add std::move().
This allowed removals of 'AllowCompilerWarnings' from layout/painting,
netwerk/cookie, and toolkit/components/extensions.
Differential Revision: https://phabricator.services.mozilla.com/D5425
--HG--
extra : moz-landing-system : lando
MSVC doesn't like AssignLiteral(condition ? "literal1" : "literal2")
even when both literals have the same length. (clang and gcc are both
happy with that)
Differential Revision: https://phabricator.services.mozilla.com/D5350
--HG--
extra : moz-landing-system : lando
* Avoid the string implementation's capacity checks, since we know they
succeed.
* Avoid the string implementation's aliasing checks, since we know there's no
aliasing.
* Avoid writing the zero terminator more than once or out of sequence.
* Use u"" literals when appending literals to a UTF-16 string.
* Write runs of non-escaped code units instead of writing code unit by code
unit in order to benefit from SIMD (either via memcpy or
ConvertLatin1toUTF16).
This results in a 13% execution time reduction on desktop Haswell i7 when
getting the innerHTML of the body of the Selectors spec. (The WebKit
optimization target from https://bugs.webkit.org/show_bug.cgi?id=81214 .)
MozReview-Commit-ID: LAg3gkGJnpQ
Differential Revision: https://phabricator.services.mozilla.com/D5239
--HG--
extra : moz-landing-system : lando
Nothing is using the xpt module anymore, which means we can remove it,
as well as the runtests.py script that runs its test, and the
integration of those tests in the build system.
Depends on D5221
Differential Revision: https://phabricator.services.mozilla.com/D5223
--HG--
extra : moz-landing-system : lando
This is the only reason I haven't used it before for things like
StyleSheet::State.
Change the underlying type to be the underlying enum representation by default,
but allow to override it if wanted.
Assertions should catch misuses.
Differential Revision: https://phabricator.services.mozilla.com/D5248
--HG--
extra : moz-landing-system : lando
Also rewrote some code around the actual problem to be more obviously correct
and comprehensible.
MozReview-Commit-ID: FF2hSjQ4U1x
Differential Revision: https://phabricator.services.mozilla.com/D5154
--HG--
extra : moz-landing-system : lando
We move the XPConnect() singleton accessor to nsIXConnect to make it available for consumers outside of XPConnect. Most of the consumers of the singleton accessor just need the nsIXPConnect public interface, except for the IsShuttingDown() member which this patch adds to nsIXPConnect as well.
Differential Revision: https://phabricator.services.mozilla.com/D5151
These properties were added in bug 478251 back when XPIDL was sort of emulating
WebIDL. They are not needed any more, and none of our XPIDL files use them.
--HG--
extra : rebase_source : f2f2c54ae787ad90704074eb114f00c3741d5f88
We move the XPConnect() singleton accessor to nsIXConnect to make it available for consumers outside of XPConnect. Most of the consumers of the singleton accessor just need the nsIXPConnect public interface, except for the IsShuttingDown() member which this patch adds to nsIXPConnect as well.
Differential Revision: https://phabricator.services.mozilla.com/D5151
Since the ABI on this platform just uses the ARM procedure call
standard, which is the same standard Unix uses, we can just
copy-and-paste everything, with some adjustments to the assembly code to
compile properly.
In many places, nsTArray::IndexOf is followed by accessing that element
(hopefully with `Elements() + index`, which skips unnecessary bounds checks.)
But this pattern introduces operations that could be avoided:
- IndexOf converts the address of the found element into an index,
- The caller must test for a special `NoIndex` value,
- On success, accesses convert that index back into the original address.
This patch introduces new 'ApplyIf...' functions that combine all these
operations in a more efficient ensemble: If the sought element is found, it is
passed by reference to a given callable object (usually a lambda); if not
found, another callable is invoked.
Depending on what they need, the first callable may take one of these parameter
lists: (), (size_t), (maybe-const elem_type&), (size_t, maybe-const elem_type&).
On top of removing the pointer->index->pointer operations in most cases,
invoking callables directly from ApplyIf is safer, as the array is guaranteed to
be untouched at this time.
Also, being templates taking function objects, in most cases the compiler should
be able to inline and optimize the search and its callables' code.
This patch gives example uses in nsTArray::Contains, and in
FrameProperties::GetInternal, SetInternal.
And FrameProperties::Has now calls Contains, which is more efficient because
the former code would compute an index (or NoIndex), and then convert that index
to a bool; whereas the new code directly produces a bool from within the search
algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D2758
--HG--
extra : moz-landing-system : lando
This restores the old allocation semantics for "append" operations between
Latin1 and UTF-16 while keeping the buffer re-use optimization for the
"assign" cases.
MozReview-Commit-ID: 8JCw3AaCNLN
Differential Revision: https://phabricator.services.mozilla.com/D3582
--HG--
extra : moz-landing-system : lando