ResolveURLUsingLocalRef is designed to be internally used by
nsSVGEffects::Get-{SVGEffect}-URI functions. Since we also need it in
SVGUseElement::LookupHref, make it public in nsSVGEffects.
MozReview-Commit-ID: Hsvs8Uzahrz
--HG--
extra : rebase_source : 54698a477a2ebb3f635fb3a77f6bc39b1741b05b
IsLocalRefURL is originally designed to be used by URLValue only. Since we need
this function in SVGUseElement::LookupHref too, move it to nsContentUtils as a
util function.
MozReview-Commit-ID: FDjWVbTfB0V
--HG--
extra : rebase_source : a3e1133f08ffad59a05c6e829f4ff416b897b917
Favicons migrated from the old store have expiration set to 0.
The code is not expecting that, since expiration has always been positive, thus
those icons are always considered valid and never replaced. They should instead be
considered expired.
MozReview-Commit-ID: Cz0JB4IbURA
--HG--
extra : rebase_source : aae2a477fe52198647a820ceb1db249316c4d72f
We were using -moz-border-*-colors in eula.css before.
We no longer need to do that, so we are changing it to use the standard css border
MozReview-Commit-ID: KvJ0kigreEt
--HG--
extra : rebase_source : d6ff70b0b425ef3a900e65c3431027e57674ced3
Favicons migrated from the old store have expiration set to 0.
The code is not expecting that, since expiration has always been positive, thus
those icons are always considered valid and never replaced. They should instead be
considered expired.
MozReview-Commit-ID: Cz0JB4IbURA
--HG--
extra : rebase_source : c9676529bd73581f3325c8a267c8863ff09767a3
Just use WebRender's ClipId directly. This will allow us to create and
use ReferenceFrames in the future, if we need to do that. It will also
make it easier to have Servo responsible for creating the root
scrolling area, which will allow removing some old hacks in the future.
<!-- 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
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they should not change behavior.
<!-- 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: 6e05a903afe81af5a45067dde4f9af26a2ea4be2
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ed3c05a3a6ad1de7c189632886473e8b9b294565
Correctly implement following step of [Dom Document Spec](https://dom.spec.whatwg.org/#dom-document-createelement):
> Let namespace be the HTML namespace, if the context object is an HTML document or context object’s content type is "application/xhtml+xml", and null otherwise.
Note, this will make following test in `tests/wpt/web-platform-tests/dom/nodes/Document-constructor.html` to fail, so related .ini file added to mark it as such:
```
test(function() {
var doc = new Document();
var a = doc.createElement("a");
// In UTF-8: 0xC3 0xA4
a.href = "http://example.org/?\u00E4";
assert_equals(a.href, "http://example.org/?%C3%A4");
}, "new Document(): URL parsing")
```
I'm not very familiar with specs, but from quick look at it, I'm doubtfull that it is valid in the first place. This is an "application/xml" document, so I don't see why it should encode a.href. Firefox also fails that.
---
<!-- 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#14095 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because because there are already tests which were being ignored
<!-- 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: 2d732d829b3fc93938898118ee55ef985ebfc657
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 7fbf8e42f1b8d08344dceb34a890ccf3fdce34df
r=heycam https://bugzilla.mozilla.org/show_bug.cgi?id=1355427
(copying over the relevant commit message so that it doesn't get lost in the vcssync)
scriptlevel is a property that affects how font-size is inherited. If scriptlevel is
+1, for example, it will inherit as the script size multiplier times
the parent font. This does not affect cases where the font-size is
explicitly set.
However, this transformation is not allowed to reduce the size below
scriptminsize. If this inheritance will reduce it to below
scriptminsize, it will be set to scriptminsize or the parent size,
whichever is smaller (the parent size could be smaller than the min size
because it was explicitly specified).
Now, within a node that has inherited a font-size which was
crossing scriptminsize once the scriptlevel was applied, a negative
scriptlevel may be used to increase the size again.
This should work, however if we have already been capped by the
scriptminsize multiple times, this can lead to a jump in the size.
For example, if we have text of the form:
huge large medium small tiny reallytiny tiny small medium huge
which is represented by progressive nesting and scriptlevel values of
+1 till the center after which the scriptlevel is -1, the "tiny"s should
be the same size, as should be the "small"s and "medium"s, etc.
However, if scriptminsize kicked it at around "medium", then
medium/tiny/reallytiny will all be the same size (the min size).
A -1 scriptlevel change after this will increase the min size by the
multiplier, making the second tiny larger than medium.
Instead, we wish for the second "tiny" to still be capped by the script
level, and when we reach the second "large", it should be the same size
as the original one.
We do this by cascading two separate font sizes. The font size (mSize)
is the actual displayed font size. The unconstrained font size
(mScriptUnconstrainedSize) is the font size in the situation where
scriptminsize never applied.
We calculate the proposed inherited font size based on scriptlevel and
the parent unconstrained size, instead of using the parent font size.
This is stored in the node's unconstrained size and will also be stored
in the font size provided that it is above the min size.
All of this only applies when inheriting. When the font size is
manually set, scriptminsize does not apply, and both the real and
unconstrained size are set to the explicit value. However, if the font
size is manually set to an em or percent unit, the unconstrained size
will be set to the value of that unit computed against the parent
unconstrained size, whereas the font size will be set computing against
the parent font size.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7919e591a46274c0d7f3a7c7c99d2643d55d60f1
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f3222c625f72aa2f70192b0efe8d50d28d7002b2
<!-- Please describe your changes on the following line: -->
This issue is reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1355005.
spec: https://developer.mozilla.org/en-US/docs/Web/CSS/box-orient
---
<!-- 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 [Bug 1355005](https://bugzilla.mozilla.org/show_bug.cgi?id=1355005)
<!-- Either: -->
- [X] These changes do not require tests in Gecko.
<!-- 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: f74f1fb59233c3f366cec4ace5df37c0264786be
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 0028688311e5bf2ca2cfee90dad07ba07ad85848
According to PR #16494, column-count should be animatable, so we should change the animation_type to "normal".
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix Bug 1355732 and PR #16494.
- [X] These changes do not require tests because we have tests in gecko already.
Source-Repo: https://github.com/servo/servo
Source-Revision: ac92bddbf5e4a8e2f68fc57883244f9c4a35d466
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c3f546fc03f7380630bcb8966c2cfe1af5d12b85
New RDM can be disabled because the user flipped a pref or because e10s is
disabled. For each of these cases, add notifications to old RDM pushing users
to switch to the new version and provide feedback, since the old RDM will
eventually be removed.
MozReview-Commit-ID: EOQ0FkuRmY0
--HG--
extra : rebase_source : 44e50bfe471cc5f85b3143d7e10d98f078b072a4
