As it turns out, the version the minidump-stackwalk tasks use (1.31), is
the first version that actually builds the project: 1.30 and earlier
fail because for some reason, cargo wants to read all Cargo.toml files
in the workspace, including unrelated ones, and barfs on features that
weren't supported until 1.31.
Differential Revision: https://phabricator.services.mozilla.com/D37020
--HG--
extra : moz-landing-system : lando
Without the change a green rectangle in each reftest in this commit covers whole
screen.
Differential Revision: https://phabricator.services.mozilla.com/D37328
--HG--
extra : moz-landing-system : lando
This class will not just decommit whole chunks, so rename it to not imply
that as much.
Differential Revision: https://phabricator.services.mozilla.com/D35589
--HG--
extra : moz-landing-system : lando
This implements the machinery for the splitting of static prefs headers, and
uses it for a single header. #includes are used in such a way that the amount
of boilerplate for each static prefs header file is minimal.
Future patches will split the remaining prefs into more header files.
Differential Revision: https://phabricator.services.mozilla.com/D36154
--HG--
rename : modules/libpref/StaticPrefs.h => modules/libpref/StaticPrefsBase.h
rename : modules/libpref/StaticPrefs.h => modules/libpref/init/StaticPrefListBegin.h
extra : moz-landing-system : lando
This should make all emails from pushes link to treeherder as requested in the bug. I've made a try push and confirmed that the "thanks for your submission" email still happens with proper links. I am pretty sure this will set the link in non-try pushes correctly but if it doesn't, nothing will actually break afaict.
Differential Revision: https://phabricator.services.mozilla.com/D37116
--HG--
extra : moz-landing-system : lando
browserElement_ScrollEvent.js is affected by this change. Before this change
the document for iframe mozbrowser was not considered as the root content
document, but after this change, it's considered as the root content document.
Given the nature of iframe mozbrowser, I believe it's the right behavior.
The browser mochitest in this commit fails without this change since
the minimum-scale size is used in the out-of-process iframe so that the visual
viewport size gets 3x bigger than the expected size.
Differential Revision: https://phabricator.services.mozilla.com/D36547
--HG--
extra : moz-landing-system : lando
Debug mochitests are running as well as opt now, and sufficient for tier 1.
Differential Revision: https://phabricator.services.mozilla.com/D37016
--HG--
extra : moz-landing-system : lando
Skipping this test clears the way for running geckoview debug crashtests, finally.
Differential Revision: https://phabricator.services.mozilla.com/D37018
--HG--
extra : moz-landing-system : lando
In the spec [1], it only considers text's alignment when computing the `position`. However, the text alignment `start` and `end` can make the same result of what `left` and `right` make, depending on what direction the text uses.
For example, setting text alignment `left` is equal to `start` for the LTR text. Therefore, we could check the result of `ComputedPositionAlign`, which would return correctly direction automatically accoding to the text's base direction.
[1] https://www.w3.org/TR/webvtt1/#cue-computed-position
Differential Revision: https://phabricator.services.mozilla.com/D35272
--HG--
extra : moz-landing-system : lando
Add new test cases for alignment `start` and `end` for both LTR and RTL text.
Differential Revision: https://phabricator.services.mozilla.com/D35271
--HG--
extra : moz-landing-system : lando
This patch adds three unit tests (in one file) to the set of the raptor tests. The tests include (i) an Android 8 power parsing test, (ii) an android 7 power parsing test, and (iii) a test for android OS baseline parsing (tested using android 8 data).
Differential Revision: https://phabricator.services.mozilla.com/D36926
--HG--
extra : moz-landing-system : lando
And with this, all tests pass on tryserver when the shared list is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D36112
--HG--
extra : moz-landing-system : lando
This is the main part of the implementation, except that it doesn't handle populating the
local names table (for @font-face src:local() lookups) with Full and PostScript names;
that follows in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D36110
--HG--
extra : moz-landing-system : lando
I'll need to add a couple of extra fields to the cache records, and realized that the current format
looks really fragile; in theory, it'd break if a font name ever contained a comma or semicolon
(unlikely though that may be). So let's fix it to be a bit more robust before we add to it further.
Using control characters from the C0 range to delimit fields/records, instead of ASCII punctuation,
removes the (tiny) risk of conflict with characters that actually occur in a name, and using
distinct field and record separators means that we can better check that the records we're loading
from the cache actually match the expected format.
(Given that the startup cache gets re-created when the build ID is updated, a change in the format
between versions wasn't going to cause problems for users; their old cache just gets blown away
when upgrading. Still, a little more robustness seems like a good thing.)
Differential Revision: https://phabricator.services.mozilla.com/D36109
--HG--
extra : moz-landing-system : lando
This makes the functional structure a bit cleaner, so that it'll be easier to slip in the alternative
codepath for the shared font-list.
Differential Revision: https://phabricator.services.mozilla.com/D36108
--HG--
extra : moz-landing-system : lando
A bit of cleanup of the existing code, before we start actually implementing new stuff.
Differential Revision: https://phabricator.services.mozilla.com/D36107
--HG--
extra : moz-landing-system : lando
This isn't really specific to the FT2 fontlist, it's a general fixup that I noticed while
working on this. (The missing checks aren't crucial, but mean that we might re-read a cmap
when we shouldn't need to.)
Differential Revision: https://phabricator.services.mozilla.com/D36106
--HG--
extra : moz-landing-system : lando
The original patch in bug 1422530 checked whether we're currently hiding a given piece of text
because we're waiting for a resource to download, and used this as a signal that we should not
initiate another download.
However, that's not really a good criterion to use when we're doing font selection for a given
character, both because it's an indirect signal -- whether painting the text is suppressed will
depend on timing and the font-display property -- and because it doesn't consider whether any
resource that's already being downloaded will actually be relevant for the specific character
we're trying to display.
So this patch instead checks for a relevant in-progress load earlier in the font list during
the specific FindFontForChar call, so that when unicode-range is used to split a font across
multiple subsets, an in-progress load for one subset won't make us defer the downloads of other
subsets if they are also needed for the characters present in the text.
With this, the repeated blinking no longer happens on the site here, as loading of all the
required font subsets is initiated early.
Differential Revision: https://phabricator.services.mozilla.com/D35634
--HG--
extra : moz-landing-system : lando
