In Bug 1323953, we always send 4-bytes prefix for completion and the prefix is also
used as the key to store cache result from gethash request.
Since it is always 4-bytes, we could convert it to integer for simplicity.
MozReview-Commit-ID: Lkvrg0wvX5Z
<!-- Please describe your changes on the following line: -->
The patch is part of fix in Bug 1341667(stylo: Figure out why all the W3C masking reftests fail)
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 7262270990f17834137dda35bdab665abd7482e0
Promise based MediaDataDecoder expects one response per request, but ICodecCallbacks was not designed that way. onInputExhausted() is called only when there are none or just a few input buffers waiting to be queued, and onOutput() is called as soon as output buffers are available. It means these 2 kinds of events are usually interleaved and hard to align with pending promises. Reporting each input buffer status makes it easier for RemoteDataDecoder to resolve promise properly.
MozReview-Commit-ID: K09txmHTtmX
Some IME may handle WM_KEYDOWN message before application and may set the keycode value to VK_PROCSSKEY but not do actually. Similarly, IME may handle WM_KEYDOWN message and replace following WM_CHAR messages with different characters.
Therefore, even if WM_KEYDOWN message comes with VK_PROCESSKEY, NativeKey shouldn't stop dispatching keypress events if it detects following printable char messages.
MozReview-Commit-ID: DcC2qgcLDrQ
This is from changeset 249a47720ddcf896a9f07600c429a1b4492b805e from
the version-control-tools repo. It contains a fix to restore
compatibility with Mercurial 3.7, which caused mozharness tests
to fail because that test pins Mercurial 3.7.3 in a requirements
file. This is a bug. But getting a modern robustcheckout deployed
is more important than upgrading that test.
<!-- Please describe your changes on the following line: -->
This is a PR of https://bugzilla.mozilla.org/show_bug.cgi?id=1354426
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because it's for stylo.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: e6a89899b0bf3e24e7f119e59a4e933bf967bb8d
File copied verbatim from changeset e0d30b04dac6bcd36b57c711d9c5b1c280f63390
from the version-control-tools repository.
The updated extension now detects and retries after network failures
where it didn't before. This should cut down on the number of
intermittent failures.
MozReview-Commit-ID: 2bFLcGEARTJ
This introduces two new statistics to the overlay. The first is the ratio of
pixel shader invocations (as determined by the GPU) to the number of pixels we
determined need to be redrawn. The ideal ratio is 1.0, indicating that we
filled every pixel exactly once. Anything over 1.0 indicates overdraw.
We also add the ratio of shaded pixels to window size. This indicates how well
we computed the invalid region, and whether or not we overfilled that
region.
Note that the OpenGL and Basic compositors do not yet query the GPU for
this statistic, so they will estimate shader invocations by the area of
DrawQuad calls.
Finally, we remove the feature where layout can request the most
recent overdraw statistic. It was not implemented on all compositors, and the
only test that used it was disabled.
