This avoids creating a compartment in every content process that does
not use the push service.
MozReview-Commit-ID: HQxrVp9DxFd
--HG--
extra : rebase_source : 4920c118c3385b73edc61980d5582f6ba0e29221
Rename UpdateTransitions as DoUpdateTransitions, and add a public
method, UpdateTransitions for stylo.
MozReview-Commit-ID: 7UiGzFsGZC4
--HG--
extra : rebase_source : a1e6a1efda9fc324ba50e5a17c122d6daf1b5b01
We use the template to replace the type, nsStyleContext and
ServoComputedValuesWithParent.
MozReview-Commit-ID: JFPdODZAwX8
--HG--
extra : rebase_source : 781c7027f9b5f2f72ae4b4cd80e7952b938a6641
We use ServoComputedStyleValues as the argument here, instead of
ServoComputedValues, because I will use template for nsStyleContext and
ServoComputedValuesWithParent in UpdateTransitions() and
ConsiderInitiatingTransition(). Besides, add an FFI to check if a
proeprty is discrete animation type.
MozReview-Commit-ID: 7VtcMDtgl55
--HG--
extra : rebase_source : eeef2e634887b66bb6650d66fb2e3929a5ea1855
We have different interpolation implementations on Gecko and Servo, so
wrap the "Can be Interpolated" in AnimationValue. This patch also introduces
the FFI, Servo_Animationvalues_IsInterpolable.
MozReview-Commit-ID: 92Yf1u84A3c
--HG--
extra : rebase_source : 544d9db1b0d377006ae42b1242dc064bd5fa65d2
We also need to update the interpolation code based on ServoAnimationValue in
ElementPropertyTransition::UpdateStartValueFromReplacedTransition().
Therefore, ElementPropertyTransition can be used by both Gecko and Servo.
MozReview-Commit-ID: BrIpvRR3te8
--HG--
extra : rebase_source : df49fdf39811dcd1661cc815dbf0b1bc192f9d81
Use AnimationValue as arguments, and add one FFI to uncompute the
value. Therefore, we can use GetTransitionKeyframes for both Gecko and
Servo backends. However, there are many "mGecko"s, which will be removed
later.
MozReview-Commit-ID: Dg5hrDdlIWb
--HG--
extra : rebase_source : 0ed36ee5a48e4d452ba812f912de6110a3139510
GetTransitionKeyframes is a simple helper function, which is only used by
ConsiderInitiatingTransition, so let's make it static to reduce the time
to revise the header.
MozReview-Commit-ID: HlztPxz8sMJ
--HG--
extra : rebase_source : 37dd1dca3956fcdd89148b2b8c7a24413c0f9aac
Remove page-icon entries when the icon changes, so that we start showing the
new content.
Also adds an SVG page-icon test.
MozReview-Commit-ID: 10MIOvwbQ20
--HG--
extra : rebase_source : 27775ada780c0c949555d5bed979e57227549bc1
Root domain icons should be retained as far as possible, and only expired when
a domain is removed from the database. We do that through the moz_hosts trigger.
Additionally, since we return root domain icons without the need for a direct
association, we can save a lot of database space and performance by not storing
associations at all for root domain icons.
This has some downsides, since we don't exactly know if the page was really
associated with that root icon or not, but the perf gains are far superior.
Note that we still create associations during migration, since it would be too
expensive to examine every single url to figure out if it's a root domain icon.
MozReview-Commit-ID: 3mlfcOV8ixC
--HG--
extra : rebase_source : 789300afb5d700095bd83aabf1a37200218ff210
When optimizing an ico file, split it into its single resources and pick only
the sizes we care about. This also de-dupes same size resources.
The migration path doesn't split ico files, since it's a performance hot path
and we should try to reduce the I/O load at that time. The worst case is that
some icons may not look that much crisp until the next page reload.
Note that while the "resource" naming would be more appropriate for ico files,
compared to "frame" that is more appropriate for animations, the patch still
uses the frame name, cause it's far less generic and can be more easily
associated with the concept of a graphical asset. Regardless, it's not exposed
in any public API.
MozReview-Commit-ID: 3vrGXzJDfjX
--HG--
extra : rebase_source : d3015836abd5f7737cab42a3b102b5d718c692d6
When an icon for a specific page is not available, try to fallback for the root
domain icon.
This is valid for both getFaviconUrlForPage and getFaviconDataforPage, as well
as the page-icon: protocol.
MozReview-Commit-ID: JC4cx1PAY38
--HG--
extra : rebase_source : f50e0d4d0ab71a0b218c3d7caaa0da149838d148
Inserting new payloads for a page should expire old ones, otherwise if the page
should change favicons, we'd retain old associations forever.
At the same time, setting multiple payloads for a page should keep working.
MozReview-Commit-ID: 2y1XLUiKAQo
--HG--
extra : rebase_source : 628e74ae66c33aa039b5f2e57c38709c2d452b3d
Both page-icon: and moz-anno:favicon: should support a simple #size=NNN ref
fragment to allow consumers to request a specific sized icon (if available).
The service will do its best to satisfy the request, but it's not guaranteed.
If no size hint is found, it will default to the biggest icon payload available.
It's currently not possible to test the fragment on moz-anno:favicon: since that
requires imagelib support to extract payloads from ico files. Thus a test will
be added at a later time.
MozReview-Commit-ID: G221MKY7rfs
--HG--
extra : rebase_source : 029a6fcaa9dadda24f8d3ebc9b36c1a0ec6314c6
Updates consumers to the new behavior.
Some consumers are changed to use the "page-icon:" protocol, since it's not
trivial to join the icons table and get a single result out of it. In most cases
the join would return multiple results since a page can have multiple icon payloads.
These consumers for now will return the biggest payload, bug 1347532 will fix
some of them to properly pass a #size=NN fragment.
Note that, even before, these were just "moz-anno:favicon:" uris, and the
payload had to be fetched from the database.
Some other consumers for now just fallback to the largest payload, by passing 0
to GetFaviconURLForPage.
The favicon optimization still happens on the main-thread, bug 1346139 will
handle that problem.
Most of the changes involve handling the modified IconData objects, that now
retain an array of payloads, rather than just one. But note that .ico files are
not yet split into single frames, due to imagelib missing APIs that will be handled
in bug 1337402.
The other changes involve fixing queries to properly join with the new tables.
Finally, note that thanks to the FOREIGN KEYS support, removing from moz_icons or
moz_pages_w_icons will also remove relations from moz_icons_to_pages.
The system only supports square icons, so icons are resized based on their larger side.
This doesn't include new tests, those will be in a following changeset.
MozReview-Commit-ID: JUkpquhpS8y
--HG--
rename : toolkit/components/places/tests/unit/test_svg_favicon.js => toolkit/components/places/tests/favicons/test_svg_favicon.js
extra : rebase_source : fa49c4a81d6ab6b34a2f19ee4175e889a6e9d734
This patch moves favicons blobs to a separate database names favicons.sqlite.
The dabatase is then ATTACHED to the main Places connection, so that its tables
can be used as if they were all part of the same database.
The favicons.database contains 3 tables:
1. moz_pages_w_icons
This is the way to join with moz_places, through page_url_hash and page_url.
We are not using the place id to avoid possible mismatches between places.sqlite
and favicons.sqlite. This way the database is "portable" and reusable even
if places.sqlite changes.
2. moz_icons
Contains icons payloads, each payload can either be an SVG or a PNG. These
are the only stored formats, any other format is rescaled and converted to
PNG. ICO files are split into single frames and stored as multiple PNGs.
SVG are distinguishable through width == UINT16_MAX
In future the table will also contain mask-icon color for SVG and average
color for PNGs.
The fixed_icon_url_hash is "fixed" to allow quickly fetch root icons, that
means icons like "domain/favicon.ico" that can also be reused for any page
under that domain.
3. moz_icons_to_pages
This is the relation table between icons and pages.
Each page can have multiple icons, each icon can be used by multiple pages.
There is a FOREIGN_KEY constraint between this (child) table and icons
or pages (parents), so that it's not possible to insert non-existing ids
in this table, and if an entry is removed from a parent table, the relation
will be automatically removed from here.
Note though that removing from the relation table won't remove from the
parent tables.
Since the relations are now many-many, it's no more possible to simply join
places with the icons table and obtain a single icon, thus it's suggested that
consumers go through the "page-icon" protocol.
The migration process from the old favicons table is async and interruptible,
it will be restarted along with the favicons service until the temp preference
places.favicons.convertPayloads is set to true.
MozReview-Commit-ID: CUCoL9smRyt
--HG--
extra : rebase_source : 4d25966596dcdf63c9c872425c5bf147406d25ac
<!-- Please describe your changes on the following line: -->
This fixes#12937 where keypresses arrive in a one-off fashion, effectively delaying each keystroke. This PR is based heavily on @codec-abc's https://github.com/servo/servo/pull/16193 PR, with some further fixes and cleanup. From the original PR comments:
> There are 2 types of events associated with keyboard: Key event (up or down) and Character Input.
>
> * A character is not necessary created one a key is pressed (like the home key).
> * A character may be created only using a combination of several key. For example, using a Qwerty International layout you have to type ` then e to get é. The first key press on ` will create no character.
> * In servo, we currently merge the 2 events together, meaning that we store a Character Input event in a field to fire a single event later on when we get a Key event.
>
> The order of events seems to be system dependent. For example, let's say that we type the A key on a Qwerty Layout. In Linux and MacOs we will get this:
>
> * Character Input for character A
> * Key down event with virtual key code of the key A
> * Key up event with virtual key code of the key A
>
> while in Windows we get:
>
> * Key down event with virtual key code of the key A
> * Character Input for character A
> * Key up event with virtual key code of the key A
>
> It seems that glutin make no attempt to reorder the event to make the order independent of the Operating System. I think it would be easier for Servo if it were handled by the library.
This fix is a stopgap for the current state of glutin. We may want to look into a deeper fix in the future. For now, this is hopefully adequate solution until a more permanent one can be found.
This is the last remaining issue for the Windows nightly blockers meta-issue https://github.com/servo/servo/issues/12125
---
<!-- 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#12937 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because they are around Windows keyboard eventing.
<!-- 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: 4c851925fbbd8446f6bfc36ff6836e9b24ad635b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ed025584e25c5979861919d48ddedfe656f32729
<!-- Please describe your changes on the following line: -->
Some check were added to make sure we can call `split_at` with no risk of panics (when value is empty or the first char is multibyte).
---
<!-- 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#15883 (github issue number if applicable).
- [x] There are tests for these changes
<!-- 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: 69eda6a60cece433e91d4bc578e94d8d5dfc9544
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 8fdafe778055c065fbc7d01f50905be85f8d956e
These are interdependent patches of Bug 1343753. We want to use ComputedValues and AnimationValues to start/update/stop the transitions.
---
<!-- 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 1343753.
- [X] These changes do not require tests because we have tests in Gecko already.
Source-Repo: https://github.com/servo/servo
Source-Revision: e817666859f381648e41b690a7e35ad22cf48bbe
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : bd521c13192c7a3b3711b6cb6d97dc27dbffa843
The scroll destination of the smooth scroller of <scrollbox> can be outside of the actual scrollable range. Therefore, it doesn't make scroll slower even when the end appears.
This patch makes the destination always in the scrollable range.
MozReview-Commit-ID: CfEGzhG7Jh7
--HG--
extra : rebase_source : 87a07140a1ce58752ac264a1e8decb2a8af6d078
Reviewed by @emilio in [bug 1353191](https://bugzilla.mozilla.org/show_bug.cgi?id=1353191).
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
Source-Repo: https://github.com/servo/servo
Source-Revision: 5f6c27bb945eba1242be2fb4812ea5095ef26377
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5b14918d20ee9b9b5cf4fe9be7b303251e6e9bb1