This changes the colors of the odd table cells and the hover state in rows in the Network tab in DevTools.
I have updated the //--table-zebra-background// in **variables.css** and inserted a new one, which is //--table-selection-background-hover//.
I have created the new variable, in order to prevent it affecting other table colors.
Differential Revision: https://phabricator.services.mozilla.com/D21777
--HG--
extra : moz-landing-system : lando
Changed the way we to access contents of `.CodeMirror`, by using `CodeMirror.getValue()` instead of `.textContent`
Differential Revision: https://phabricator.services.mozilla.com/D22079
--HG--
extra : moz-landing-system : lando
- Add separate function to import fixture files instead of treating them like
test files. This simplifies the code structure a bit and avoids unnecessary
output spew, because the test262 test record parser no longer complains about
missing yaml frontmatter.
- Write reftest terms into a new test262/jstests.list file for raw tests.
- Allow including nested jstests.list files in _parse_external_manifest.
Differential Revision: https://phabricator.services.mozilla.com/D21677
--HG--
extra : moz-landing-system : lando
Make sure we shutdown the mitmproxy process in case the setup fails.
Differential Revision: https://phabricator.services.mozilla.com/D22467
--HG--
rename : testing/mozbase/mozproxy/tests/test.py => testing/mozbase/mozproxy/tests/test_proxy.py
extra : moz-landing-system : lando
The Timestamp implementation on Windows seems to be based off of two system APIs: GetTickCount64 and QueryPerformanceCounter. QPC seems to be preferred over GTC, unless a "failure" in QPC is detected.
There is code in the Timestamp implementation to detect if QPC "fails" be comparing elapsed time of QPC to elapsed time of GTC.
Through logging on try server I observed the following in different failures:
1) the QPC failure detection kicks in a lot and disables use of QPC
2) the QPC of the vsync timestamp was in the future compared to the QPC of TimeStamp::Now().
3) the QPC of TimeStamp::Now() was missing (presumably because it was disabled) and the GTC of the vsync timestamp was in the future compared to the GTC of TimeStamp::Now()
4) the vsync timestamp printf of raw GTC and QPC values matched at the source (SoftwareDisplay::NotifyVsync) and in the refresh driver, so the vsync timestamp wasn't getting messed up.
I guess we could spend more time on the error detection in our Windows TimeStamp code, but this failure is only happening on 32-bit machines.
Here's a patch to disable the assertions on 32-bit Windows. Depends how important we think this assertion is relative to the work to investigate more.
Differential Revision: https://phabricator.services.mozilla.com/D22453
--HG--
extra : moz-landing-system : lando
Report when recipes don't match the filter. Report when Jexl filters
themselves fail, with an added test.
The existing test for remote-settings usage had a bug, so fix that
too.
Depends on D22017
Differential Revision: https://phabricator.services.mozilla.com/D22018
--HG--
extra : moz-landing-system : lando
There is a bug on Adreno GPUs where glBlitFramebuffers always writes
to the 0th layer of a texture array, regardless of which layer is
actually attached to the draw framebuffer.
With picture caching enabled on webrender, the cached pictures were
all being drawn to the 0th layer of the picture cache texture array,
leaving the other layers blank. This was resulting in the wrong
content being drawn on one tile of the screen, and the rest being
black.
This works around this by blitting to an intermediate renderbuffer,
then using glCopyTexSubImage3D to copy from the renderbuffer to the
correct texture layer.
Differential Revision: https://phabricator.services.mozilla.com/D22305
--HG--
extra : moz-landing-system : lando
Same for blit_render_target_invert_y(). Make them wrappers around the
private function blit_render_target_impl(), which uses the currently
bound read and draw targets as before.
Differential Revision: https://phabricator.services.mozilla.com/D22304
--HG--
extra : moz-landing-system : lando
This flag is only used by IonAnalysis and rarely so it should be
computed there instead of in all script/function code paths.
Differential Revision: https://phabricator.services.mozilla.com/D22432
--HG--
extra : moz-landing-system : lando
The way the copy-on-write stuff works, and the way that we have to apply
properties from most specific to less specific guarantees that always that we're
going to inherit an inherited property, or reset a reset property, we have
already the right value on the style.
Revert relies on that, so there doesn't seem to be a reason to not use that fact
more often and skip useless work earlier.
Font-size is still special of course... I think I have a way to move the
specialness outside of the style, but piece by piece.
Differential Revision: https://phabricator.services.mozilla.com/D21882
--HG--
extra : moz-landing-system : lando
The only fishy bit is the animation stuff. In particular, there are two places
where we just mint the revert behavior:
* When serializing web-animations keyframes (the custom properties stuff in
declaration_block.rs). That codepath is already not sound and I wanted to
get rid of it in bug 1501530, but what do I know.
* When getting an animation value from a property declaration. At that point
we no longer have the CSS rules that apply to the element to compute the
right revert value handy. It'd also use the wrong style anyway, I think,
given the way StyleBuilder::for_animation works.
We _could_ probably get them out of somewhere, but it seems like a whole lot
of code reinventing the wheel which is probably not useful, and that Blink
and WebKit just cannot implement either since they don't have a rule tree,
so it just doesn't seem worth the churn.
The custom properties code looks a bit different in order to minimize hash
lookups in the common case. FWIW, `revert` for custom properties doesn't seem
very useful either, but oh well.
Differential Revision: https://phabricator.services.mozilla.com/D21877
--HG--
extra : moz-landing-system : lando
This seems to make more sense as it is currently only handling the search service.
Differential Revision: https://phabricator.services.mozilla.com/D22351
--HG--
rename : browser/components/search/test/browser/SearchTestUtils.jsm => toolkit/components/search/tests/SearchTestUtils.jsm
extra : moz-landing-system : lando
`PresShell::EventHandler::HandleEventInternal()` needs to accumulate event
handling time per each event type. The handling start time needs to be
recorded before sending EventStateManager. Therefore, this patch makes the
helper class which is a stack class, records current time at construction
and calls `Telemetry::AccumulateTimeDelta()` at destruction automatically.
Differential Revision: https://phabricator.services.mozilla.com/D21335
--HG--
extra : moz-landing-system : lando
Sam Foster
Ciure Andrei
Nicolas Silva
Lee Salzman
Ashley Hauck
Ted Campbell
Mellina Yonashiro
Michael Ratcliffe
John Dai
Byron Campen [:bwc]
Hemakshi Sachdev
André Bargull
Emily Toop
Micah Tigley
Mathieu Leplatre
Tarek Ziadé
Mark Banner
Timothy Nikkel
Ethan Glasser-Camp
Jamie Nicol
Jason Laster
Henrik Skupin
Emilio Cobos Álvarez
Andrew Halberstadt
Sylvestre Ledru
Dão Gottwald
Masayuki Nakano
Nupur Baghel