Changes to the desktop_nightly filter chain selected only tasks with no
shipping_product attribute set or tasks where it is set to "firefox".
This led to the decision task optimizer removing a large portion of the tasks
that run as part of Thunderbird's nightly builds.
This update adds "thunderbird" to the list of shipping_product's whose tasks
are kept in the task graph.
Differential Revision: https://phabricator.services.mozilla.com/D18872
--HG--
extra : moz-landing-system : lando
The fix for build bug 1512541 causes an Android build issue. The issue has been fixed upstream in LMDB's development branch, but the fix hasn't made it to LMDB's release branch. So I backported it to a branch in the mozilla/lmdb-rs repo, and this change switches to that branch to fix the Android build issue.
Differential Revision: https://phabricator.services.mozilla.com/D18767
--HG--
extra : moz-landing-system : lando
The test run with e10s disabled, and the test failure happens by disabling e10s. But WebRender is not used on windows with disabling e10s. Then we could skip the test for MVP.
Differential Revision: https://phabricator.services.mozilla.com/D18810
--HG--
extra : moz-landing-system : lando
Previously, popup widgets with empty bounds would not be hidden.
Non-popup GTK widgets with empty bounds would be hidden during ResizeClient().
Skipping the resize for popups is only appropriate when they are hidden.
Differential Revision: https://phabricator.services.mozilla.com/D17394
--HG--
extra : moz-landing-system : lando
Simply remove unused class member mHasQueryString and HasQueryString() method.
Differential Revision: https://phabricator.services.mozilla.com/D18694
--HG--
extra : moz-landing-system : lando
And for now, start blocking custom cursors that are larger than 64 pixels.
I wish I knew how to add a test for this, but I tested manually using the
test-case from bug 1518189 with and without hidpi.
We always treat the cursor image size as CSS pixels (and upscale it to device
pixels in HiDPI). We have bugs to stop doing that though (bug 1425694).
Differential Revision: https://phabricator.services.mozilla.com/D18671
--HG--
extra : moz-landing-system : lando
We want to indicate "we didn't actually manage to define your properties as
non-configurable" but we don't want to throw exceptions when people try to
Object.defineProperties with a non-configurable property in the list on a
WindowProxy.
Though maybe we should just silently ignore the "can't define non-configurable
on WindowProxy" bits in defineProperties and just return the object anyway?
The reason we do the "return null" bit in defineProperty is so that Caja and
the like can detect it, but if they're not using defineProperties to start with
they may not need to detect this "failure". On the other hand, Mark Miller
thinks the detection will be needed...
Differential Revision: https://phabricator.services.mozilla.com/D17516
--HG--
extra : moz-landing-system : lando
This adds a new configure option `--enable-wasm-codegen-debug`, which defaults
to true in debug builds (disable otherwise).
It's a first step so as to be able to use this in both the shell and browser,
using the env variables JIT_OPTION_{JitOption field name}.
Differential Revision: https://phabricator.services.mozilla.com/D18341
--HG--
extra : moz-landing-system : lando
We should replace the context.autofillValue property with a result.autofill property. When the view selects results, it already notifies the input about it by calling input.setValueFromResult(). So we can modify setValueFromResult to check for the presence of result.autofill and thereby get autofill "for free". (The one place where the view doesn't call input.setValueFromResult() when a result is selected is when it selects the preselected result, so this patch adds that.)
result.autofill is an object: { value, selectionStart, selectionEnd }
This is going to help me implement bug 1521702.
One potentially cool thing about doing autofill this way is that any result can now trigger autofill, not only the heuristic result, and do it easily. Of course the user isn't typing when they select a non-heuristic result, so it's probably not fair to call that "autofill", but the result can trigger the selection aspect of autofill. As one example, that might be interesting for search suggestions: Type "foo", key down to the "foobar" suggestion, and the "bar" substring is automatically selected.
Differential Revision: https://phabricator.services.mozilla.com/D18618
--HG--
extra : moz-landing-system : lando
This ensures the corresponding section is shown for event pings in
about:telemetry, even if there's no actual data for the parent process.
This avoids a bigger rewrite of the logic of what sections and processes to display.
Differential Revision: https://phabricator.services.mozilla.com/D18805
--HG--
extra : moz-landing-system : lando
Dustin J. Mitchell
Rob Lemley
ui.manish
John Dai
Myk Melez
sotaro
Wes Kocher
Boris Zbarsky
Ashley Hauck
Bogdan Tara
Brad Werth
Yuan Cheng
Dzmitry Malyshau
Jan Henning
Kershaw Chang
Emilio Cobos Álvarez
Narcis Beleuzu
Mark Banner
Jason Laster
Nabil Lamrabet
Brindusan Cristian
Benjamin Bouvier
Drew Willcoxon
shindli
k88hudson
Jan-Erik Rediger
Florin Strugariu
Mike de Boer
Jon Coppeard
Andreas Tolfsen
Oana Pop Rus
Matthew Noorenberghe
Miko Mynttinen
Mike Hommey