This gets rid of the sending warnings to the browser console. Instead, when the processor is explicitly asked to do so, it now collects spec violations into a `moz_validation` member.
To access the new manifest member, you can now pass a second argument to `ManifestObtainer.contentObtainManifest()` like so:
```
const manifest = await ManifestObtainer.contentObtainManifest(
this.targetActor.window,
{ checkConformance: true }
);
manifest. moz_validation; // 🎉
```
Differential Revision: https://phabricator.services.mozilla.com/D36885
--HG--
extra : moz-landing-system : lando
it's very helpful to see the list of clips and the way they affect a chased primitive
Example:
```
building clip chain instance with local rect TypedRect(1561.0×1968.0 at (-300.0,-300.0))
clip Rectangle(3840.0×1874.0, Clip) at (0.0,0.0) in space SpatialNodeIndex(1)
flags (empty), resulted in Partial
clip Rectangle(3840.0×1874.0, Clip) at (0.0,0.0) in space SpatialNodeIndex(2)
flags (empty), resulted in Partial
```
Differential Revision: https://phabricator.services.mozilla.com/D37137
--HG--
extra : moz-landing-system : lando
In this patch, we do the following changes.
1. using Ahem and using it as recommanded font size and line height.
2. reduce the cue text length in `align_center_position_lt_50.vtt` and `align_center_position_gt_50.vtt` in order to prevent text wrapping to multiple lines
3. wrapping to mulitple lines would be tested in `align_center_position_lt_50_size_gt_maximum_size.html` and `align_center_position_gt_50_size_gt_maximum_size-ref.html`
Differential Revision: https://phabricator.services.mozilla.com/D35695
--HG--
extra : moz-landing-system : lando
According to the spec [1], the background box should be `display:inline`.
Therefore, we should create a `<span>`, which already is an inline element, for the background box, not a `<div>`, which is a block element.
In addition, when the pseudo element is enabled, even though the element is currently a `div`, it doesn't match the div `{ display: block; }` rule from the UA style sheet because the pseudo element only matches `::cue` rules. It also has the initial value of display which is `inline`.
[1] https://www.w3.org/TR/webvtt1/#webvtt-cue-background-box
Differential Revision: https://phabricator.services.mozilla.com/D36849
--HG--
extra : moz-landing-system : lando
If the background node is not a pseudo element, these properties would actually be inherited, so we have no need to set them again.
Differential Revision: https://phabricator.services.mozilla.com/D36848
--HG--
extra : moz-landing-system : lando
In order to clearly see what properties are applied on the root node, create a function to list all of them together.
Differential Revision: https://phabricator.services.mozilla.com/D36847
--HG--
extra : moz-landing-system : lando
Setting cue's position would also affect cue box's size which would be determined by cue's position alignment as well. If the cue box's width or height is zero, it means that this box should not be display on the screen and we should clear cue's display state as well.
Differential Revision: https://phabricator.services.mozilla.com/D35693
--HG--
extra : moz-landing-system : lando
Previously, DocAccessibleParent::AddChildDoc used the presence of a BrowserBridgeParent to determine whether the child document was in a different process to the parent document.
While this is normally the case, there can be a point while the embedded document is loading where there is a temporary document in the same (embedder) process.
In this case, we tried to get the COM proxy for the child document.
For a child document in the same process, this isn't available yet, so this caused infinite recursion (stack overflow) in ProxyAccessible::GetCOMInterface.
Instead of using the presence of BrowserBridgeParent, first check whether the child document is at the top level of its content process.
If it isn't, the document is in the same process as its parent.
Also, add a DIAGNOSTIC_ASSERT to ProxyAccessible::GetCOMInterface which will fire if no COM proxy or MSAA child id has been set.
Previously, we just recursed infinitely and overflowed the stack in this case, which is painful to debug.
Differential Revision: https://phabricator.services.mozilla.com/D37344
--HG--
extra : moz-landing-system : lando
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
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
