Remove conversion for computed `line-height` value to unitless value to prevent Font Editor from crashing when the patch from [Bug 1536871](https://bugzilla.mozilla.org/show_bug.cgi?id=1536871) is applied (the default computed value for `line-height` is no longer numeric).
Add support for `normal` keyword value for `line-height` as the default returned by `getComputedStyle()`, similar to existing behavior for `letter-spacing`.
Fix misnomer of the class in `LetterSpacing.js` component.
Differential Revision: https://phabricator.services.mozilla.com/D35394
--HG--
extra : moz-landing-system : lando
Added a top margin for about:addons inline settings page such that
the paddings would be consistent.
Differential Revision: https://phabricator.services.mozilla.com/D34817
--HG--
extra : moz-landing-system : lando
A test case is added to make sure this is fixed.
We also add the ability to not run a given test case in the color test.
Differential Revision: https://phabricator.services.mozilla.com/D35493
--HG--
extra : moz-landing-system : lando
The problem is that on switching back to the first tab (see the bug), userTypedValue is non-null when URLBarSetURI is called. Therefore the proxy state can't be valid. Something about bug 1529931 caused userTypedValue to go from null to non-null in this case. Details below, but the summary is that we shouldn't be calling UrlbarInput.setValueFromResult when opening the history popup, because setValueFromResult sets userTypedValue.
Before bug 1529931, result.autofill would always be undefined for the first result in the history popup, because we didn't allow UnifiedComplete to return an autofill result for the search triggered by the history popup. After that bug, UnifiedComplete could return an autofill result in that case -- and it likely would since the first result in the history popup has a very high frecency, which also makes it eligible for autofill.
The problem with having an autofill result in the history popup is that it triggers the input.setValueFromResult() call in UrlbarController.receiveResults [1], and setValueFromResult sets userTypedValue. So when the user opens the history popup, userTypedValue gets set to a non-null value (input._lastSearchString).
The fix is to not allow autofill for the history popup. After making that fix on revision https://hg.mozilla.org/mozilla-central/rev/5e2a3b886e64, the bug went away.
However, after I made that fix on a fresh tree, the bug still happened. It turns out that input.setValueFromResult still ends up getting called, by UrlbarView._selectItem [2], which is called when results are received [3]. The fix for this afaict is just to pass `updateInput: false` to _selectItem.
The autofill-related fix doesn't seem to be necessary at all anymore (likely due to the substantial changes to autofill since that bug landed), but I left it in anyway since it seems right to not allow autofill results for the history popup.
One other useful bit of info is that userTypedValue is set to null by tabbrowser on page load [4], so that's how userTypedValue has a null value when the bug manifests and it goes from null to non-null.
[1] https://hg.mozilla.org/mozilla-central/file/5e2a3b886e647af1968b9e52a6672bdeee2a0d6f/browser/components/urlbar/UrlbarController.jsm#l150
[2] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/components/urlbar/UrlbarView.jsm#685
[3] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/components/urlbar/UrlbarView.jsm#220
[4] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/base/content/tabbrowser.js#5118
Differential Revision: https://phabricator.services.mozilla.com/D35505
--HG--
extra : moz-landing-system : lando
No one includes `license.hunspell`, so we don't need our custimze block (`#include "config.h"`)
Also, some files isn't updated to 1.6.1, so we should update it.
Depends on D35516
Differential Revision: https://phabricator.services.mozilla.com/D35517
--HG--
extra : moz-landing-system : lando
This changes CreateClippedDrawTarget so that instead of taking
a max size and a transform it just takes a user space rect of
the desired bounds.
This change allows the caller to not worry about the computing
a max size based on the current clip. Instead this responsibility
is lowered into the specific backends.
The main motivation for this work is to allow blob recoordination
to create recordings that don't depend on the current clip.
Some additional benefits are that the API is easier to use and
as can be seen simplifies the SVG masking code because it doesn't
need to track surface offsets manually.
It's also an important step towards removing all the uses of
gfxContext::GetClipExtents which will let us get rid of the separate
clipping stack in gfxContext and help us move off of gfxContext
completely.
Most backend implementations of CreateClippedDrawTarget are relatively
simple. DrawTargetCapture is modified to track the current clip rect
so that it can create a new DrawTargetCapture of the appropriate size
without needing to worry about lazy resolution.
Differential Revision: https://phabricator.services.mozilla.com/D33363
--HG--
extra : moz-landing-system : lando
Due to how highlighters work, it requires the inspector to be initialized.
It can happen than the user will mouseenter/mouseout on an element that
calls highlight/unhighlight very quickly.
Since the hightlight can take some time, it might happen that the unhighlight
call is handled first, before the highlight call, meaning that we now have an
highlighter displayed, even though the user isn't hovering anything that
should cause this anymore.
This patch introduces a new toolbox function called `getHighlighter` that
returns an object with a `highlight and a `unhighlight` function.
We keep a reference to any possible pending `highlight` call so we can wait
for it to be done in `unhighlight`, before destroying it.
The console makes use of the new helper function, and a test is added to ensure
we don't have zombie highlighters anymore.
Differential Revision: https://phabricator.services.mozilla.com/D34562
--HG--
extra : moz-landing-system : lando
This moves the html plugin enabling from the ./mach command line to the configuration, which means editors can pick this up automatically.
Differential Revision: https://phabricator.services.mozilla.com/D35414
--HG--
extra : moz-landing-system : lando
Windows 1-tier PGO builds only partially clobber between the
profile-generate and profile-use stages, so that exports/installed files
don't have to be reprocessed. Unfortunately we can't skip the install
manifests in 3-tier PGO because the profile-generate build happens on a
different machine, so we have to differentiate between 1-tier and 3-tier
PGO builds. A new variable, MOZ_1TIER_PGO, is used for this purpose.
Eventually this logic can be cleaned up in bug 1557788 once all PGO
builds use the 3-tier model.
Differential Revision: https://phabricator.services.mozilla.com/D34802
--HG--
extra : moz-landing-system : lando
Our version of mozmake in Windows has issues with how it shells out to
commands that contain double-quote characters. For
example:
FOO="bar" $(PYTHON) script.py
behaves differently than:
FOO='bar' $(PYTHON) script.py
With a double-quote anywhere in the command-line, backslashes get
slurped, so Z:\task/foo becomes Z:task/foo, and python fails to open the
file.
The backslash comes from the WORKSPACE variable in Taskcluster, which is
used in many places, so it seems prudent here to simply convert the
backslash to a forward-slash as a workaround for the issue. Another
possible workaround is to change WORKSPACE to use forward-slashes, and
work around any potential issues with that.
Differential Revision: https://phabricator.services.mozilla.com/D34801
--HG--
extra : moz-landing-system : lando
With clang-cl and PGO enabled, toolchain.configure automatically turns
on LTO for compatibility with MSVC. However, MOZ_PGO is set for both the
profile-generate and profile-use builds in a 3-tier PGO setup via
imply_option(), but we only want LTO enabled for the profile-use build
(see bug 1483778).
For 1-tier PGO builds, which are still used by local developers, MOZ_PGO
will be set and --enable-profile-generate will be unset, so LTO will be
automatically enabled. The profiledbuild target in make is responsible
for disabling MOZ_LTO on the profile-generate build.
For 3-tier PGO builds, MOZ_PGO will still be set, so we can skip setting
LTO in configure when --enable-profile-generate is set.
Differential Revision: https://phabricator.services.mozilla.com/D34800
--HG--
extra : moz-landing-system : lando
Windows finds llvm-profdata in the PATH, in contrast to Linux or Android
builds that set LLVM_PROFDATA as an environment variable in mozconfigs.
The pgo_profile_path() configure checks should still work in this case.
Differential Revision: https://phabricator.services.mozilla.com/D34799
--HG--
extra : moz-landing-system : lando
MOZ_PGO_PROFILE_USE is set when the use-pgo attribute is defined in the
task. This environment variable is used to enable --enable-profile-use
and related configure flags.
Differential Revision: https://phabricator.services.mozilla.com/D34798
--HG--
extra : moz-landing-system : lando
The run-profileserver.sh script is a bridge between the Taskcluster task
and profileserver.py. It was originally written as a Linux-only script,
but with a few modifications it can support Windows as well. The xvfb
support needs to be optional, and the UPLOAD_PATH and PGO_RUNDIR
variables must not assume a Linux filesystem.
Differential Revision: https://phabricator.services.mozilla.com/D34796
--HG--
extra : moz-landing-system : lando
The ServiceWorker is terminated by idleWorkerTimer timeout, and in slow platforms/machines, it would cancel the uncompleted fetching and make unexpected behavior during running tests.
The SW idle termination implementation has no defects, so the fix would just double the dom.serviceWorkers.idle_timeout to let fetchings have more chance to finish before idleWorkerTimer timeout.
Differential Revision: https://phabricator.services.mozilla.com/D35555
--HG--
extra : moz-landing-system : lando
See https://stackoverflow.com/a/24026735.
Adding the `docs` package requirement is not ideal, but it's not worth
the effort to install it only in automation (or in the relevant task),
and it's not *that* large: 1.0G on my macOS installation.
Differential Revision: https://phabricator.services.mozilla.com/D35834
--HG--
extra : moz-landing-system : lando
4.3.3 is the strict minimum required for v-c-t's config wizard, but it
is preferable people use more modern versions. We could go with 5.0, but
it feels like people still using 4.8 and 4.9 don't really need to be
bugged to update to a more recent version, they are kind of modern
enough. OTOH MozillaBuild comes with 4.5.x, and this will force an
upgrade for those.
Differential Revision: https://phabricator.services.mozilla.com/D35756
--HG--
extra : moz-landing-system : lando
