It seems like a footgun to expose raw pointers to WebRenderAPI which is
a refcounted object. Let's only expose it via refcounting pointers.
MozReview-Commit-ID: AKmTZg2V99r
--HG--
extra : rebase_source : 805f13d56a64bafbcdf3bf4266eec47c70856564
These days (at least with webrender enabled), the layers id is created
by mashing together two uint32 values into the uint64. Printing it as in
base 10 produces some large number near the 32-bit boundary, and it's
much more legible/easier to compare when printed in hex.
MozReview-Commit-ID: JsGhqyLtDBv
--HG--
extra : rebase_source : ed60d26d8223d968f37e8d933e60b1ee6552d1e9
We only label Object as being ArrayLike if they have consecutive, numeric indexes, starting at 0,
and that could contain only a non-numeric length property that matches the actual number of numeric
keys in the object.
A test is added to make sure we don't regress this.
Fix old console frontend tests which relied on the bad implementation of ArrayLike (and delete
test cases now covered by the server test).
MozReview-Commit-ID: ATF7WypNVhh
--HG--
extra : rebase_source : 5e6a0ef0da84cf89518164f518a257bd1f0d5fd8
Update known requirements for building.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19238.
Source-Repo: https://github.com/servo/servo
Source-Revision: b2b51d333e99c1d2a7322ae53357f2b095ba2d40
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 7a8a1c0a960f0d7fd1309a29c90fde9cea8a17f8
This allows enabling properties in ua sheets and chrome differently.
The setup is:
* enabled_in needs to be one of the four values:
["", "ua", "chrome", "content"]
* "chrome" implies "ua", and implies that they're explicitly enabled.
* "" implies the property will never be parsed.
* "content" implies the property is accessible unconditionally, modulo a pref.
Experimental still keeps trumping over those when the pref is enabled.
This PR replaces uses of internal="" by enabled_in="ua" or enabled_in="".
This may seem that it changes behavior, but since the properties where I added
enabled_in="" already unconditionally error from parse it's not.
Next step is annotating chrome-only properties.
Source-Repo: https://github.com/servo/servo
Source-Revision: a757fb14cf6938000824fc6cb756acd0176adb9a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a146c96ffab697436ab4def69afd92f2b4a7361f
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
Since NotifyDataEnded() run its code asynchronously, it is possible that a new
channel is created and NotifyDataStarted() is called before NotifyDataEndedInternal()
has a chance to run. We check the load ID to exit the function if necessary.
We also need to fix data races when running NotifyDataEndedInternal() off the
main thread in next patches.
MozReview-Commit-ID: IIAc7dxHike
--HG--
extra : rebase_source : 58e45f924058a986b8d86bfaeff2791ee8a5f4bc
extra : intermediate-source : b2a7fa7514723e214b8da40cfc0ec40b1de9a345
extra : source : 1ff93dc8f8c451b804133c780cedef2ee3d348e5
It is a good practice to make the call flow simplier. It also makes
the changes in the following patches easier.
MozReview-Commit-ID: CKjRBReLFro
--HG--
extra : rebase_source : 1903b0648b718541af9f796dfa664209552f47d2
extra : intermediate-source : 12ffa8e5cb637dbb4d425d6b2ddae6c7574f767a
extra : source : a1d92c67ec461f8fda88546fd1f0be0c00c39dc7
Resolves#19283
Do "Wrap" functions only created for elements that aren't marked Abstract in .webidl file?
How can I see code that was generated from webidls?
<!-- 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#19283 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because they are covered by webplatform 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: db5fb74a4d3ff4c354edac8e116ed4f5665d61a5
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4335c80ba64d6f3022831b7cc8f302dcca0d5186
The idea is the following:
Behind-window vibrancy is mostly rendered by the window server. For a given
vibrant region of a window, the window server renders a vibrancy "backdrop",
which is a blurred version of everything that's behind that region, modified
with a color tint and blended in some way. Then it puts our actual window
contents on top of that background.
The backdrop's shape is usually a rectangle. If we don't want it to be a
rectangle, we need to tell the window server about the shape that we want it to
be. We can't just "draw" a different shape in our own rendering, because our
own rendering is merely placed on top of the backdrop - but here we want to
modify the shape of the backdrop itself.
NSVisualEffectView lets us set a mask image on the view. If this view is the
content view of a window, then the view will automatically communicate the mask
image to the window server.
Traditionally, our popup windows have had a ChildView as their content view. If
we now want an NSVisualEffectView to be the content view of the window, then we
need to nest the ChildView inside that NSVisualEffectView.
But this NSVisualEffectView is only needed when the window is vibrant and the
vibrancy backdrop needs to have a certain shape. This is the case for our menus
which need to have rounded corners. If the window transitions to being
non-vibrant, or not needing a special shape, then we can go back to the way our
window's NSView hierarchy has worked traditionally. So we need to reparent
NSViews during those transitions.
MozReview-Commit-ID: Bo2VzjhhR0A
--HG--
extra : rebase_source : 0434a17e2cddc94715db6a5fd17bc27e2cddd05c
<!-- 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 part of #19015.
<!-- Either: -->
- [X] These changes do not require tests because these are just refactoring.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6361aed46d5246037d636669dc64664971e94279
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 11a5347c800976c3699403bc9fee00e78f1c56e4
I don't know why GetInsertionPrevSibling would get the parent wrong.
IsValidSibling handles the frameset case and a lot of the table caption cases.
The table caption cases IsValidSibling can't handle are due to elements which
create frames based on something other than display.
For those cases, while IsValidSibling will return incorrect results, we will end
up seeing that the parent frame is the wrong type after creating the frame
construction items for the new stuff and reframe under WipeContainingBlock.
MozReview-Commit-ID: 5b3L4CB6Oxl
--HG--
extra : rebase_source : c3559dae0b5f4de72fbf5031bdded48f79df6216
