This was working around some old XUL layout weirdness, but nowadays this uses the same scroll frame implementation as HTML and tabStrip.scrollPosition + tabStrip.scrollClientSize > tabStrip.scrollSize cannot be true.
MozReview-Commit-ID: F5fOEpXn8ay
--HG--
extra : rebase_source : 5dcd0282e1054aad1c1a4946dd98dc33549bd2d6
<!-- Please describe your changes on the following line: -->
Little proposals
---
<!-- 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
- [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 _____
<!-- 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: 320cfeb2909ff061552194f02147f4b50b6a1450
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ebf83c8688036f5c995e6801c95665dbbf3c389c
This patch matches Chrome's behavior almost exactly, except it uses a slightly
different formula for the deltaY value that results in the same movement speed
as Chrome but doesn't drift over time.
Tested by confirming that trackpad pinch zoom now works on maps.google.com,
wego.here.com, and figma.com.
`beginGestureWithEvent` and `endGestureWithEvent` are not called for
applications that link against the macOS 10.11 or later SDK when we're running
on macOS 10.11 or later.
For compatibility with all supported macOS versions, we have to call
{begin,end}GestureWithEvent ourselves based on the event phase when we're using
the 10.11+ SDK.
See: https://developer.apple.com/reference/appkit/nsresponder/1526368-begingesturewithevent
NO_TLS used to be hardcoded on mac because up to 10.6, __thread was not
supported. Until recently, we still supported for 10.6, and it's not the
case anymore, so we could make mac builds use __thread.
Unfortunately, on OSX, __thread circles back calling malloc to allocate
storage on first access, so we have an infinite loop problem here.
Fortunately, pthread_keys don't have this property, so we can use that
instead. It doesn't appear to have significantly more overhead (and TLS
overhead is small anyways compared to the amount of work involved in
allocating memory with mozjemalloc).
At the same time, we uniformize the initialization sequence between
mozjemalloc and mozjemalloc+replace-malloc, such that we have less
occasions for surprises when riding the trains (replace-malloc being
nightly only), ensuring the zone registration happens at the end of
mozjemalloc's initialization.
The function, when passed `true`, creates a new arena with no attachment
in the global list of arenas, and assigns it to the current thread.
When passed `false`, it restores the default arena.
Some details are left out because they don't matter yet, as the sole
initial use of the API is going to invoke the function when stylo rayon
threads start up, which happens exactly once per thread, and at thread
exit time, which happens at shutdown, if ever.
This simplifies things, and leaves those details to followup(s):
- Arenas can't simply be killed when the function is called with `false`
again (or when the thread dies) because they may still contain valid
allocations that could have been passed to other threads. Those arenas
should be kept until they are empty.
- jemalloc_stats doesn't know about them and will under-report memory
usage.
- pre/post fork hooks don't know about them and will not force-unlock
their locks. In practice, until those arenas are used for something
else than the style system, this can't lead to the dead-locks that
these hooks help prevent because nothing should be touching pointers
allocated through them after fork.
It was inconsistent with gecko side and also we needed to pass nsCompatibility enum along with URLExtraData.
MozReview-Commit-ID: 2ceutBfqBrg
--HG--
extra : rebase_source : f342774ed349c65f377cf85865f5905520784ca5
r=bholley in bugzilla
---
<!-- 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 1360488](https://bugzilla.mozilla.org/show_bug.cgi?id=1360488)
Source-Repo: https://github.com/servo/servo
Source-Revision: 94ac822132bd78a412f847a704c9ddf3eb91151c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2ea77efd7e0f31ea403f9952644c6ff30aaf4466
As per SVG spec [1], we should also parse negative color components values for
SMIL, but currently Gecko does not support it either.
[1] https://www.w3.org/TR/SVG/implnote.html#RangeClamping
MozReview-Commit-ID: FH80zN3jyKh
--HG--
extra : rebase_source : c9b435222ee7e84cb6e84064a62b2b866e75b6eb
assert_parsing_mode_match() is mostly the same as
assert_restyle_hints_match().
MozReview-Commit-ID: 7oOHlZ06DYk
--HG--
extra : rebase_source : 2ace9d66f64c1cfc11c17ded37fdabf356f57d5c
We need another flag that represents allow-negative-number for SMIL, so
this enum will also comprise the another parsing mode that allows negative number.
MozReview-Commit-ID: IDFNppjGeB
--HG--
extra : rebase_source : 456f661b33346ff4a756a66c6accf4ab1a5f2f80
<!-- Please describe your changes on the following line: -->
This is a PR for https://bugzilla.mozilla.org/show_bug.cgi?id=1357295 .
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: 0900ad4e4e980040f4c89da0bcc7bb52ca0aabd4
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 77c1a873d20cb1f416ebb443e6b9267b48bf9ac1
https://bugzilla.mozilla.org/show_bug.cgi?id=1363572https://reviewboard.mozilla.org/r/138092/
---
<!-- 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
- [ ] 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: b80d4acef455d1072df5a4ad7fd1d80fbff8e27c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 30999e7e6f547eaa40e5bb027768ab986de207af
