This also adds a GetVariablesObject helper so we don't have to duplicate the
logic there.
Differential Revision: https://phabricator.services.mozilla.com/D13698
--HG--
extra : moz-landing-system : lando
Also add widget.allow-gtk-native-file-chooser preference value to force enable on all systems.
Differential Revision: https://phabricator.services.mozilla.com/D16184
--HG--
extra : moz-landing-system : lando
This patch introduces a Redux selector for the Changes slice. A selector here is a fancy word for a method that returns a subset from the state without having to expose the state's structure to the consumer. It is also useful for returning a derived version of the state which we're using here.
The tracked changed CSS rules in the Redux state are not stored in a nested structure. A shallow structure is easier to query and to work with in our use case. But the Changes panel needs to display CSS rules in a hierarchical structure (ex: a style rule which is a child of a @media rule). To do this, the React component used to build up the nested structure as it consumed the changes from the Redux state. To prevent rendering duplicates of rules (once as part of an ancestor's children and once as a standalone rule), the React component kept a reference of rules it had previously rendered. This had a flaw because it didn't account for the rule's stylesheet. The problem was that rules with identical selectors from different stylesheets would not all be rendered because they would be accidentally marked as previously rendered.
This is too much knowledge of the business logic for the React component anyway.
The Redux state should present itself in a way that's simple for the React component to consume. Hence the introduction of the `getChangesTree()` selector in this patch. This method allows us to present a comfortable structure to React while keeping the Redux structure comfortable for us to work with. This separation enables increased flexibility to restructure the Redux state without impacting the React components.
More about Redux selectors here: https://redux.js.org/recipes/computing-derived-data
Differential Revision: https://phabricator.services.mozilla.com/D16068
--HG--
rename : devtools/client/inspector/changes/moz.build => devtools/client/inspector/changes/selectors/moz.build
extra : moz-landing-system : lando
During a "first paint" transaction, compositor-side state such as APZ's copy
of the visual viewport offset is overwritten. However, the scroll frame may
persist on the main thread, and in such a case we want to restore the visual
viewport offset stored in the scroll frame. This comes into play during e.g.
navigation back to a page.
Differential Revision: https://phabricator.services.mozilla.com/D16238
--HG--
extra : moz-landing-system : lando
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
This mouse click seems superfluous, as window.focus() is called immediately after.
In addition, this click is somehow causing a page up scroll, as it's clicking
a slider frame. This causes the test to fail with scroll anchoring enabled,
for some reason. Removing this click seems to be the easiest solution, as it
doesn't seem intentional.
Differential Revision: https://phabricator.services.mozilla.com/D16276
--HG--
extra : rebase_source : 6e41d587e54d083b0930173d12db1fc180ae70fa
extra : histedit_source : a604e48df440974b7554b6ee8be01641abd92a64
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
Jan de Mooij
Mark Banner
Martin Stransky
Arnaud Bienner
Razvan Caliman
Johann Hofmann
Razvan Maries
Gabriele Svelto
Andreea Pavel
Matt Woodrow
Mike Hommey
Daniel Varga
Botond Ballo
Brian Hackett
Masayuki Nakano
Ryan Hunt
sotaro
Cosmin Sabou
Emilio Cobos Álvarez
Shanavas M
Cameron McCormack
Eric Rahm
Bas Schouten
Robert Strong
Sean Stangl
Nathan Froyd