This patch uses a promise queue to serialize reads and writes to the
livemarks cache.
MozReview-Commit-ID: 8R7N6ORxrtV
--HG--
extra : rebase_source : 864fce259ed85fc6779dec6e7707cf30899288b3
m-c, c-c and bluegriffon don't use this interface. So we should remove this.
MozReview-Commit-ID: 92VwGKlrOw5
--HG--
extra : rebase_source : 003763c6abc1406bcffabbffc3fe0696985ee97a
<!-- Please describe your changes on the following line: -->
r? jdm
Moved the following functions from components/script/dom/bindings/interface.rs to a new file components/script/dom/bindings/htmlconstructor.rs:
- html_constructor()
- get_constructor_object_from_local_name()
- pop_current_element_queue()
- push_new_element_queue()
---
<!-- 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#19179.
<!-- Either: -->
- [X] These changes do not require tests
<!-- 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: 07fd6155aae8579f1a30ea99af3549c413240f24
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 28bc09e28368565f2f4050676e233ff133fb9407
This is important because it ensures we release the shared memory handle
(although not the data itself) for the underlying surface buffer when it
turns out we will probably never need to share it. If we do need to
share the surface data with the GPU process, it will reallocate a handle
if necessary, and close it when it is finished. On some platforms we
only have a finite number of handles, so if we don't need them, we
should close them.
This is largely trivial because the meat of the implementation is
located in ImageResource and we already added GetFrameInternal.
Interestingly VectorImage::IsUnlocked does not actually check if the
image is locked, but instead only checks for animation consumers. This
is consistent with its historical behavior on when to issue an unlocked
draw event.
Note that we do not implement the original GetImageContainer and
IsImageContainerAvailable APIs. This is because the former does not
accept an SVG context and it would be best to discourage its use in old
code lest we get incorrect/unexpected results.
No functional change aside from the implementation from
VectorImage::GetFrameAtSize being repurposed for GetFrameInternal and
returning an additional error code with the surface.
Creating a DrawTarget can be an expensive operation. This is especially
true in this case because checking for a cached already decoded version
of the VectorImage is expected to be fast. Currently VectorImage::Draw
is the typical path to render these images, but in the future, getting
the frames directly or indirectly (through an ImageContainer) will
become more common.
Since `SetItemAnnotation` already queries `moz_bookmarks`, we can fetch
and pass the changed bookmark's info directly to
`nsNavBookmarks::NotifyItemChanged`, without going through the anno
observer.
This patch refactors the internal `Set*` methods to pass an optional
`BookmarkData` from `SetItemAnnotation`, and fire `OnItemChanged`
notifications after notifying anno observers. `NotifyItemChanged` also
updates the bookmark's last modified time if requested.
MozReview-Commit-ID: Hz5qiOmAjsD
--HG--
extra : rebase_source : 37170f4661341e3a401f8210ceec84cbf439b4b2
This is a regression by bug 1403690. After landing this, some xpcshell tests
cause crash with stylo.
mozilla::java::GeckoAppShell::GetShowPasswordSetting doesn't work on xpcshell
test. If JNI isn't available such as xpcshell, we shouldn't use this method.
MozReview-Commit-ID: AUrT93SkQ2H
--HG--
extra : rebase_source : 2147a42633ea98e3a4d891af832f28c105d5dcf8
In order to determine if we need to re-run configure, we write
a JSON file representing the evaluated mozconfig. If this JSON
file changes, configure (and config.status for that matter) is
out of data and it is re-executed.
This commit moves the generation of that JSON file to Python.
MozReview-Commit-ID: 636rpSY7gOm
--HG--
extra : rebase_source : ee1defd74decfd64ffb66a45b053dada58de04fb
This is a pretty straightforward port of the logic. But we
even go a step further: we delete the file in the objdir if there is
no source mozconfig!
MozReview-Commit-ID: AHFFzy6mXRY
--HG--
extra : rebase_source : 1b9387bd72f5a8e9bf8274f5764b0db0176fdba2
extra : source : 0cab9a382d817e6fbab9daa37db0f23e7f73e71f
This target isn't referenced elsewhere in client.mk. It appears to be
dead.
When this target became orphaned, I don't know. I suspect at some point
some included .mk file attempted to "include autoconf.mk." But I'm not
sure what file that would have been or when it would have changed.
FWIW, autoconf.mk is generated by config.status, courtesy of it being
listed in CONFIGURE_SUBST_FILES.
MozReview-Commit-ID: AcPrihAou11
--HG--
extra : rebase_source : 68b1b19428d0754884515c42250353bd75407784
The file is a filtered version of the make file that we previously
started generating for client.mk. Why there is special casing for
UPLOAD_EXTRA_FILES, I'm not sure. This smells fishy and is something
I'd like to take a look at once all code is ported out of client.mk.
The removal of the logic from client.mk meant that we could remove
a bunch of code from client.mk related to loading mozconfig files.
We can now simply include the auto-generated make file directly and
be done with it.
MozReview-Commit-ID: 4M5NElQA7iR
--HG--
extra : rebase_source : 87ed98fa62513007c6fdd2df00eb871a5a29a146
extra : source : 247617a64b7c438528f97d10c86e2f7b8cb72237
We write the file that client.mk is printing from Python. We can
also log it from there pretty easily. So do that.
MozReview-Commit-ID: 7eeugdOJR5b
--HG--
extra : rebase_source : 308826e948fa20684bbc40c806322f802689627e
Upcoming commits need to move more logic from client.mk. It will
be easier if we have a list of lines in the mozconfig as a local
variable.
MozReview-Commit-ID: 1wFZTfWLGP9
--HG--
extra : rebase_source : 5e3c408fdf7f953e9cbac1c4a57fd5fa87f8fbbc
Create hit-test info items (if enabled) for each frame that is not
invisible to hit-testing. This is not optimized at all yet, so it
creates a lot of display items if enabled.
MozReview-Commit-ID: LFqoaZ9e99F
--HG--
extra : rebase_source : 8a4a6bf912f88b35f2ed86f9a84ddb74e69bde38
This also adds a flag to the nsDisplayListBuilder to better control
the creation of these items.
MozReview-Commit-ID: BbeRGDjd2ie
--HG--
extra : rebase_source : ec36114d3c7eefffcf9612fc2da1aaf1353c35d8
This exposes some functions on wr::DisplayListBuilder to set hit-test
info and to do hit-tests.
The mechanism to set hit-test info is made a little more generic than is
actually used in this patchset, because doing it this way allows for
more optimization possibilities.
Specifically, the API allows setting some hit-testing state which is then
applied to all display items that are created until that state is
updated or cleared. An alternative would be to specify the hit-testing
state explicitly when creating particular display items; however doing
that would force the call sites that create the display items to compute
or obtain the hit-testing state, which would make the code less
encapsulated and harder to refactor/optimize.
MozReview-Commit-ID: EJoCFv83iu8
--HG--
extra : rebase_source : d2a117a52144f76dcc312de2a4047298e78135cb
This introduces a enum bitset type that encapsulates some of the
interesting properties that frames have that make it interesting for
hit-testing in the compositor. This type is designed so it can be sent
directly to webrender and gotten back in the hit-test.
MozReview-Commit-ID: GCxV7ZaoJd1
--HG--
extra : rebase_source : a9cc5ecfc7c5baeab2f6e08cd2ee2c2a7756e20c
Add a new |offerer| field to RTCStatsReport.
Based on offerer, label the local sdp as offer or answer.
Based on offerer, label the remote sdp as offer or answer.
MozReview-Commit-ID: 4jdWP8tpr9w
--HG--
extra : rebase_source : 5724645ef8e39c2af0c5fccf7d7872ee2cb437b5
This allows firefox and thunderbird builds to avoid using each others bits.
MozReview-Commit-ID: KYQYDd2tkGj
--HG--
extra : rebase_source : 42f1d13ec609f066cb3bd3050ed894296b72d982
This is a sub-PR of #19015
r? @emilio
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19246
- [x] These changes do not require tests
Source-Repo: https://github.com/servo/servo
Source-Revision: b4c274d190b039443101ba34a3dd84112edfe314
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5e90d778801ac494f6b78445e5c243ffc8bed7eb
