Create a zip of all UWP packaging artifacts.
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#24282
- [x] There are tests for these changes
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24417)
<!-- Reviewable:end -->
Add secure connection start
Implementing `secure_connection_start` as well as we can, this is related to #21268
We are setting the value as well as we can since we don't have a way to know if we are currently using a secure transport or where the handshake before the connection is done as the spec says on the step 15 [https://w3c.github.io/resource-timing/#sec-process](https://w3c.github.io/resource-timing/#sec-process)
Regarding the Timing Allow Check, that's being done on another PR by another person which will take care of setting the rest of the values on `PerformaceResourceTiming` to Zero and prevent them to set them any other way.
I'm currently setting the `secure_connection_time` using `precise_time_ms()` as the `connection_start` and `connection_end` are set that way... but other attributes inside `PerformanceResourceTiming` are set using `precise_time
Another thing, the issue talks about setting `redirect_start` but I'm not really sure if it's related, if so I can look up into that too... I might have just read and thought it was all about secure connection start.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix#21268
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because ___
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23990)
<!-- Reviewable:end -->
don't send progress event for empty blob
<!-- Please describe your changes on the following line: -->
---
<!-- 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#24289 (GitHub issue number if applicable)
<!-- Either: -->
- [X] 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. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24312)
<!-- Reviewable:end -->
webgl: Clear the drawing buffer when preserveDrawingBuffer is false.
This adds an explicit clear operation to a webgl canvas when the preserveDrawingBuffer attribute is false when creating the context. Because we're not using double buffering this may end up making some demos worse (ie. a clear operation at a random time while drawing a frame), but this problem is expected to go away when #24256 is fixed and we move to a multi-buffered frame setup. This change is important at this time because so many babylon.js demos rely on the engine clearing the frame, per the specification.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#21132
- [x] There are tests for these changes
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24386)
<!-- Reviewable:end -->
Update iovec
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] 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. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24411)
<!-- Reviewable:end -->
Remove obsolete logic for LRUCache size
The LRUCache implementation has been replaced, and no longer requires a backing store larger than its capacity.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24339)
<!-- Reviewable:end -->
Sync WPT with upstream (09-10-2019)
Automated downstream sync of changes from upstream as of 09-10-2019.
[no-wpt-sync]
r? @servo-wpt-sync
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24407)
<!-- Reviewable:end -->
Fetch: ensure consistency between response, done-chan, and cache state.
This ensures that when a cached response is not used because it requires revalidation, the done chan is set back to `None`(since the cache might have set it to `Some` when constructing the response requiring revalidation).
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix#24399 (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. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24401)
<!-- Reviewable:end -->
Websocket: use ipc router to handle ws dom-action messages
<!-- Please describe your changes on the following line: -->
Use the ipc router as opposed to spawning a dedicated thread.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] 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. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24402)
<!-- Reviewable:end -->
Mostly renaming for clarity, as the gradient parsing code is a bit hairy.
This also changes -webkit- gradients, which is, I think, the right thing to do
(otherwise I need to give up on the type system and sprinkle parse_non_negatives
around, which would be unfortunate).
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1008112 on
Chromium still accepting negative radii for those, so will wait to submit the
patch for review until they reply there with their intentions.
Differential Revision: https://phabricator.services.mozilla.com/D47141
We always check StyleWillChangeBits_TRANSFORM bit together with a
transform-like property set, so using WillChangeBits::TRANSFORM bit to
represent all transform-like properties is ok.
However, it seems the new test case works well even if we don't have this
patch. I still add it for individual transform properties to make sure
the test coverage is enough anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47509
Also, update the serialization by the shorter perference because this is
a new feature and using older syntax doesn't make sense.
Besides, use `cssOffset` for web animation IDL attribute name.
Differential Revision: https://phabricator.services.mozilla.com/D45607
* Let layout.css.use-counters.enabled be independent from the unimplemented
property counters.
* Always count in the style system (that is, always create
Document::mStyleUseCounters), so that the warning from bug 1582374 works
irrespective of these prefs.
* Add a pref check to the SVGElement code path so that the prefs properly
reflect whether the histograms end up being recorded or not.
* Make the pref checks consistent (check both when reporting telemetry, not
earlier).
Differential Revision: https://phabricator.services.mozilla.com/D46633
This is in the interests of allowing the frontend team to experiment with
switching from XUL grid to CSS grid, without inadvertently changing the
display values for the grid items via css-grid-item blockification.
This patch's new pref is not expected to remain in the codebase for long.
We're just adding it so that the behavior remains the same by default, because
we do currently have some XUL code that inadvertently depends on -moz-box
display values being blockified to 'block'. The plan is for folks to remove
that dependency e.g. by adding explicit 'display:block' styling to frontend
code as-needed. After we've done that, we can tentatively flip the pref to true
by default, and then remove the pref entirely.
Differential Revision: https://phabricator.services.mozilla.com/D45258
Currently, there's no way to tell whether the SIDEWAYS bit is set from
`writing-mode:sideways-*` or `writing-mode:vertical-*; text-orientation:sideways;`.
To be able to tell them apart, split SIDEWAYS bits into VERTICAL_SIDEWAYS
and TEXT_SIDEWAYS. This is needed by my proposed solution in bug 1102175.
Also, provide convenience methods related to sideways writing-mode, and replace
obscure checks in the codebase.
Note that we don't have the use cases to distinguish vertical-rl from
sideways-rl in layout, but for the completeness, IsSidewaysLR() is still
defined.
Differential Revision: https://phabricator.services.mozilla.com/D46321
1. Add `generics::motion::OffsetPath`, and use specified `Angle` and
computed `Angle` to define specified `OffsetPath` and computed `OffsetPath`.
2. Add `ray` function into `OffsetPath`.
We also tweak the degree from 150deg to 135deg in wpt (e.g.
offset-path-ray-001.html and others) to avoid floating point precision issues.
For example:
```
// offset-path: ray(150deg ...);
// offset-distance: 20px;
matrix:
{
{0.500000 0.866025 0.000000 0.000000},
{-0.866025 0.500000 0.000000 0.000000},
{0.000000 0.000000 1.000000 0.000000},
{10.000000 17.320509 0.000000 1.000000}
}
// rotate(60deg) translate(20px)
matrix:
{
{0.500000 0.866025 0.000000 0.000000},
{-0.866025 0.500000 0.000000 0.000000},
{0.000000 0.000000 1.000000 0.000000},
{10.000000 17.320507 0.000000 1.000000}
}
```
Their translate parts, 17.320509 vs 17.320507, are almost the same (only
tiny difference), which may cause the reftest failed.
Differential Revision: https://phabricator.services.mozilla.com/D42721
