Depends on D122577
When using the BiDiSession class we need the event loop to live at
least as long as a specific connection, but not necessarily as long as
the BiDISession object itself. Therefore we move the loop parameter
into the start() method, to associate a loop with a specific connection.
In addition, in the tests we make the event loop a global so that it
lives as long as a session; the fixture is updated to reuse the
existing loop where possible. This has the tradeoff that we're more
likely to share a loop between tests, so there is some additional
hidden shared state.
Differential Revision: https://phabricator.services.mozilla.com/D124834
More emphasis testcases that fail because of reference renderings that don't quite match, in addition to
some simple typos ("sample" vs "Simple").
There's some redundancy here between the testcases coming from different authors, but for now I haven't
tried to rationalize that aside from dropping a duplicate individual test for 'filled dot'.
Differential Revision: https://phabricator.services.mozilla.com/D124795
The text-emphasis-position testcases do not match the current spec, as they use the keywords 'above'
and 'below', whereas CSS Text Decorations actually specifies 'over' and 'under'. (I guess they were
created before the values were finalized.)
We also need to convert the reference lines from using abs-pos to try and simulate emphasis mark rendering
to a ruby-based version, as this is how the spec defines the rendering of the marks. The abs-pos approach
is at best an approximation, and will result in spurious reftest failures even when the emphasis properties
are working as intended.
Depends on D124793
Differential Revision: https://phabricator.services.mozilla.com/D124794
The screenshots of this testcase show that even though the text-emphasis-color property is working
as expected, the reftest nevertheless fails because the exact position of the emphasis marks
does not match between test and reference.
Applying the suggested IPAMincho font, which has fixed-width Latin characters, in place of the
default (proportional) font makes it come closer to matching, but still not quite.
The root of the problem is that it tries to compare the rendering of emphasis marks with a
"simulated" emphasis mark created by reducing the font size and using absolute positioning to
try and put the mark in a suitable position. However, the actual rendering of the emphasis mark
is not defined in such terms, and matching it will be difficult and fragile.
The spec actually defines the rendering of emphasis marks to be equivalent to ruby text, so a
more reliably correct reference rendering can be created using ruby elements with the expected
emphasis-mark characters. (I note that there are already some emphasis testcases that use this
approach.)
Differential Revision: https://phabricator.services.mozilla.com/D124793
When we had:
@layer A.B;
We were registering "A" and "B", not "A" and "A.B", which was the intention.
Fix is trivial.
Depends on D124620
Differential Revision: https://phabricator.services.mozilla.com/D124621
This makes layer order use a fixed set of bits per nesting level, to "reserve"
bits for children before they are registered.
See the comment in LayerOrder for the implementation limits it imposes, and
potential alternatives if these limits are not enough (but I think they should
be).
Enable the tests, as they mostly pass now (commit incoming to fix the remaining
ones).
Differential Revision: https://phabricator.services.mozilla.com/D124620
It was moved in bug 1495798 for rusttests, because they didn't use
client.mk, but as of bug 1683797, they do. And it turns out that when
sccache is really started as originally intended, inheriting the make
jobserver, the build is dead-locked until sccache quits (because sccache
still has a jobserver token for some reason). But sccache never quits
when we make it stop outside client.mk.
Differential Revision: https://phabricator.services.mozilla.com/D124728
When the `FAIL` text goes away, there could be some antialiased fringe left which
caused the test to fail. Use Ahem font to reduce likelihood of this
happening again.
Depends on D124067
Differential Revision: https://phabricator.services.mozilla.com/D124423
The autofocus attribute could run scripts while it's autofocusing
which may run the promise_tests, so that the focus() usage
in the tests could become nested focusing steps.
Differential Revision: https://phabricator.services.mozilla.com/D123861
More emphasis testcases that fail because of reference renderings that don't quite match, in addition to
some simple typos ("sample" vs "Simple").
There's some redundancy here between the testcases coming from different authors, but for now I haven't
tried to rationalize that aside from dropping a duplicate individual test for 'filled dot'.
Depends on D124794
Differential Revision: https://phabricator.services.mozilla.com/D124795
The text-emphasis-position testcases do not match the current spec, as they use the keywords 'above'
and 'below', whereas CSS Text Decorations actually specifies 'over' and 'under'. (I guess they were
created before the values were finalized.)
We also need to convert the reference lines from using abs-pos to try and simulate emphasis mark rendering
to a ruby-based version, as this is how the spec defines the rendering of the marks. The abs-pos approach
is at best an approximation, and will result in spurious reftest failures even when the emphasis properties
are working as intended.
Depends on D124793
Differential Revision: https://phabricator.services.mozilla.com/D124794
The screenshots of this testcase show that even though the text-emphasis-color property is working
as expected, the reftest nevertheless fails because the exact position of the emphasis marks
does not match between test and reference.
Applying the suggested IPAMincho font, which has fixed-width Latin characters, in place of the
default (proportional) font makes it come closer to matching, but still not quite.
The root of the problem is that it tries to compare the rendering of emphasis marks with a
"simulated" emphasis mark created by reducing the font size and using absolute positioning to
try and put the mark in a suitable position. However, the actual rendering of the emphasis mark
is not defined in such terms, and matching it will be difficult and fragile.
The spec actually defines the rendering of emphasis marks to be equivalent to ruby text, so a
more reliably correct reference rendering can be created using ruby elements with the expected
emphasis-mark characters. (I note that there are already some emphasis testcases that use this
approach.)
Differential Revision: https://phabricator.services.mozilla.com/D124793
It's interesting case, and it perhaps should be tested in WPT for web-compat.
Chrome 93 passes all tests in the new WPTs, but Gecko fails in the cases of
related to focus (i.e., `execCommand` and user input).
Differential Revision: https://phabricator.services.mozilla.com/D124725
Right now we ignore all the possible thrown "session not created"
errors unless the session id is not set. This is specifically
problematic for the BiDi session creation, which would fail
silently in case it cannot be created.
Differential Revision: https://phabricator.services.mozilla.com/D122625
There is a driver bug on Adreno 3xx devices causing incorrect
rendering when flat scalar varyings are used in fragment shaders. This
has occured several times in different shaders, so this patch finally
adds a test to ensure it does not occur again.
We have used the glsl crate to parse and validate the shaders rather
than angle, as exposing the required bindings to mozangle is messy. We
must therefore use the pre-optimized shaders as the glsl crate does
not handle preprocessor directives correctly.
This has been implemented as a wrench test rather than a unit test as
running unit tests on android is difficult. Additionally we want to
use the shaders specific to the platform the tests are ran on, the bug
only affects (some) android devices, and shaders on other platforms
may differ.
Differential Revision: https://phabricator.services.mozilla.com/D124205
There is a driver bug on Adreno 3xx devices causing incorrect
rendering when flat scalar varyings are used in fragment shaders. This
has occured several times in different shaders, so this patch finally
adds a test to ensure it does not occur again.
We have used the glsl crate to parse and validate the shaders rather
than angle, as exposing the required bindings to mozangle is messy. We
must therefore use the pre-optimized shaders as the glsl crate does
not handle preprocessor directives correctly.
This has been implemented as a wrench test rather than a unit test as
running unit tests on android is difficult. Additionally we want to
use the shaders specific to the platform the tests are ran on, the bug
only affects (some) android devices, and shaders on other platforms
may differ.
Differential Revision: https://phabricator.services.mozilla.com/D124205
TAO-match.html had been reenabled in bug 1726445 on Sep 03.
share-empty.https.html had been modified in bug 1726091 on Sep 03.
Differential Revision: https://phabricator.services.mozilla.com/D124616