So that it's easily available during painting.
The flag is set based on nsIPresShell::mIsFirstPaint, but the pres shell
flag is cleared at the beginning of the paint, so we can't query it from
the pres shell during the paint.
Differential Revision: https://phabricator.services.mozilla.com/D16237
--HG--
extra : moz-landing-system : lando
Due to renaming nsContentIterator.cpp to ContentIterator.cpp, Document.cpp
and FragmentOrElement.cpp are compiled in a unified cpp file now. However,
both of them have same name constant, kNSURIs and some build systems claim
that it in FragmentOrElement.cpp is never used.
Fortunately, each of them is used only by one method. Therefore, this patch
moves the each declaration into each user method.
Differential Revision: https://phabricator.services.mozilla.com/D16186
--HG--
extra : moz-landing-system : lando
This patch makes ContentIteratorBase, PostContentIterator, PreContentIterator
and ContentSubtreeIterator classes non-refcountable because most users can
create their instances in stack and such users may be in a hot path. So,
we can save a lot of cost of instantiation.
Unfortunately, only ScriptableContentIterator creates one of the concrete
classes and needs to destroy it properly. Therefore, its
EnsureContentIterator(), destructor, traverse and unlink code becomes messy.
However, ScriptableContentIterator was designed for automated tests and we
need to maintain it not so many times. Therefore, improvement of other
users must be worthwhiler than this demerit.
Differential Revision: https://phabricator.services.mozilla.com/D15928
--HG--
extra : moz-landing-system : lando
Now, nobody requires nsIContentIterator interface. So, we can get rid of it.
Unfortunately, there is no macro to keep the inherited class,
ContentSubtreeIterator, in the cycle collection to make it keep managing
ContentSubtreeIterator::mRange without nsISupports interface. Therefore, this
patch moves it into ContentIteratorBase temporarily. Anyway, the following
patch makes those classes not refcountable. At that time, this issue will be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D15927
--HG--
extra : moz-landing-system : lando
nsFilteredContentIterator is used only by TextServicesDocument and there is
no reason that it should be derived from nsIContentIterator except consistency.
Additionally, it's now only class which is derived from nsIContentIterator
except ContentIteratorBase. So, after this change, we can get rid of
nsIContentIterator completely.
This patch moves nsFilteredContentIterator into mozilla namespace and
makes TextServicesDocument treat FilteredContentIterator directly instead of
nsIContentIterator interface.
Differential Revision: https://phabricator.services.mozilla.com/D15925
--HG--
rename : editor/spellchecker/nsFilteredContentIterator.cpp => editor/spellchecker/FilteredContentIterator.cpp
rename : editor/spellchecker/nsFilteredContentIterator.h => editor/spellchecker/FilteredContentIterator.h
extra : moz-landing-system : lando
Now, all users of PostContentIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15923
--HG--
extra : moz-landing-system : lando
Now, all users of PreContentIterator can access it directly. This patch makes
them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15922
--HG--
extra : moz-landing-system : lando
Now, all users of ContentSubtreeIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15920
--HG--
extra : moz-landing-system : lando
Currently, ContentIterator is created with a bool flag to decide whether the
instance lists up post-order or pre-order. However, this is not clear. For
example:
nsCOMPtr<nsIContentIterator> preOrderIter = new ContentIterator(false);
This is not clear whether this does right thing or not.
This patch makes any users can create PostContentIterator for post-order
iterator, and creates PreContentIterator for pre-order iterator. So, now,
each creator needs to writhe above as:
nsCOMPtr<nsIContentIterator> preOrderIter = new PreContentIterator();
or
nsCOMPtr<nsIContentIterator> postOrderIter = new PostContentIterator();
Additionally, with this change, if each user starts to use concrete classes
directly, compiler can stop using virtual calls because of all concrete
classes are now marked as "final".
Differential Revision: https://phabricator.services.mozilla.com/D15918
--HG--
extra : moz-landing-system : lando
First, we should move nsContentIterator and nsContentSubtreeIterator into
mozilla namespace and then, remove "ns" prefix.
Additionally, this patch separates the definition of the classes into
ContentIterator.h and exposes it as "mozilla/ContentIterator.h". This allows
everybody access those concrete classes.
Differential Revision: https://phabricator.services.mozilla.com/D15917
--HG--
rename : dom/base/nsContentIterator.cpp => dom/base/ContentIterator.cpp
rename : dom/base/nsContentIterator.cpp => dom/base/ContentIterator.h
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
This disables NSS_ALLOW_SSLKEYLOGFILE in beta in release in order to avoid shutdown hangs until the NSS project has time to fix the root cause of the issue.
--HG--
extra : rebase_source : 51c84d4841308d283f993a7fda576031d7c4f449
The command-line parameter used by nsEmbedFunctions.cpp is turned into
an nsIFile, and then said nsIFile is never used. Its last use was
deleted in bug 1407693, where we reworked how extra annotations were
done.
Because MSVC compilers only support one architecture, we need to search
"cl" in different toolchain search paths for each of the host and
target, especially when they are different.
Likewise for the library paths for the linker. Ideally we'd pass
-LIBPATH both for host and target, but that has implications for rust
that I don't want to have to figure just now.
Depends on D15263
Differential Revision: https://phabricator.services.mozilla.com/D15264
--HG--
extra : moz-landing-system : lando
While it was preferable to use lld-link with msvc for performance
reasons when we defaulted to compile with msvc, now that we build with
clang-cl by default, it's now better to use msvc's linker when using
msvc's compiler, especially for aarch64, which is the last place where
we actually need msvc.
Differential Revision: https://phabricator.services.mozilla.com/D15262
--HG--
extra : moz-landing-system : lando
Like for other windows platforms. This currently doesn't make a
difference, but will with next change.
Differential Revision: https://phabricator.services.mozilla.com/D15181
--HG--
extra : moz-landing-system : lando
This patch also removes the last vestiges of the old architecture dropdown
structure, and removes a use of GetBinaryTypeW because it doesn't seem to
return a useful result for any ARM ISA.
Differential Revision: https://phabricator.services.mozilla.com/D14811
--HG--
extra : moz-landing-system : lando
Android mercilessly kills the parent in low memory situations, and we
don't want that to trigger a crash when the child is abruptly
disconnected.
Differential Revision: https://phabricator.services.mozilla.com/D16234
--HG--
extra : moz-landing-system : lando
None of the values tested against OS_TEST are actually possible per
split_triplet in build/moz.configure/init.configure, so the code is
dead in practice.
Differential Revision: https://phabricator.services.mozilla.com/D16161
--HG--
extra : moz-landing-system : lando
LLVM_PROFDATA needs the toolchain search dir, per bug 1515579.
Also, most of the options actually don't do anything useful with
artifact builds. In fact, the only one that artifact builds would need
is MOZ_PGO. So we move to options back to toolchain.configure, somewhere
late enough ; except MOZ_PGO, that we move to the top-level
moz.configure (because we don't need a separate file for one option).
Differential Revision: https://phabricator.services.mozilla.com/D16152
--HG--
extra : moz-landing-system : lando
Botond Ballo
Daniel Varga
Masayuki Nakano
sotaro
Cosmin Sabou
Emilio Cobos Álvarez
Shanavas M
Mike Hommey
Cameron McCormack
Eric Rahm
Bas Schouten
Robert Strong
Sean Stangl
Nathan Froyd
Jed Davis
Hector Zhao
Zibi Braniecki
Kartikaya Gupta
Ashley Hauck
Matt Howell
James Willcox