The main difference between Linux and other platforms is that mozglue is
a static library and doesn't include the allocator, while it is a
dynamic library and includes the allocator on other platforms.
As such, linking against mozglue alone doesn't guarantee everything that
should be linked is linked, which GeckoProgram() does. But since
webrtc-gtest doesn't want to link libxul, we use linkage=None.
--HG--
extra : rebase_source : 552b123cb4ef6a861a49bc5eea0f03b9b5427e8b
It doesn't appear we simply check for a wifi connection type anywhere so the
existing code shouldn't need to be updated.
MozReview-Commit-ID: 7MqIbdB7uRI
--HG--
extra : rebase_source : 4a42a080b37104fb49f1f1cfbec884edbab52ba2
Basic skeleton for implementing CanvasRenderingContext2d.fillText, only adding methods and parameters in the right place, and a basic test, with some `println!()`.
<!-- Please describe your changes on the following line: -->
This is only the beginning. It were my first couple of hours looking at Rust and Servo.
However, I have _no clue_ how to get the text to render now (basically go from the `println!()` to something else).
It's also possible I messed something up with the `DOMString.parse()` but not entirely sure.
I'm doing this PR as a starting point to get help and learn more about this, _or_ at least maybe save someone some time while implementing this, if no one's able to take the time and show me where/how.
Because it's still a work-in-progress, I'm leaving the boxes below unchecked (even though there are no errors).
---
<!-- 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#11681 and #17963
<!-- Either: -->
- [x] There are tests for these changes
<!-- 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: acd08c75f7ac87d4a61e214816a5f6d47c4a1310
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 28459e12e1ce761004c6a94d9800bb899310627c
In geckodriver we need a better control about the behavior of the
crash reporter. It should be enabled by default if possible, but
never show its window when a crash actually happens. Both settings
will allow us later to analyze the generated minidump files.
Further the crash reporter will shutdown Firefox now in case of
content crashes. This prevents a possible hang of Marionette
when a command in content gets executed and the framescript
gets disconnected.
MozReview-Commit-ID: DV1E7yQlElM
--HG--
extra : rebase_source : 6273a2f45fbe5f1b21c099ed8efcea44d72ec8e3
Some xpcshell tests run with _windowless_ browser and calls its LoadURI().
It then failed to get `aBrowser.contentWindow` when we tried to create OA
and detected if the browser was in the private mode.
MozReview-Commit-ID: DWGMyfao1wG
--HG--
extra : rebase_source : c8ed703221aa84ead8288dc7c1f200838808792b
The triggeringPrincipal needs to be consistent with the given userContextId.
MozReview-Commit-ID: Ao4hokoIcLb
--HG--
extra : rebase_source : b342a8020960e7e1028c0230ebfc0daf41c60d43
In chrome process, we often know which url is going to be loaded.
As a performance optimization, we can start initiating network
connection before sending out the 'LoadURI' message to the content
process.
MozReview-Commit-ID: L79ylHOaxX8
--HG--
extra : rebase_source : cc3aeefedde21dc8eaaf37c67710980b0204f4dc
Fix the file access check by adding missing parentheses to isDirectory method call.
Don't run the cookies file check on Linux because the test profile is read accessible due to being in /tmp.
MozReview-Commit-ID: lps2hk8f5U
--HG--
extra : rebase_source : 5fba75d65081e56df5a0d171c41689c489a3aace
Fix ping selector popup is sometimes hard to dismiss.
MozReview-Commit-ID: KEFcmq6cvRA
--HG--
extra : rebase_source : e2a6b13bd7f355aa88e47c50347d03aee5f0fa57
Asynchronously load handlers.json for nsHandlerService-json.js in
order to avoid blocking IO early on.
MozReview-Commit-ID: F3THSxvXR7I
--HG--
extra : rebase_source : 95d5ccb545cd7d8a09f80586fc2bf2dcf1ea5ab7
The main motivation behind this change is to make testing easier, so e.g:
./mach try fuzzy --no-push
and
./mach try syntax --no-push
both work the same way.
MozReview-Commit-ID: LmjA3Kq7xKN
--HG--
extra : rebase_source : 49beb7e1ae0f7502966ebadc4d9c37cae4357df4
This will give us a good way to share arguments between subcommands.
MozReview-Commit-ID: KmXRj8TBvYK
--HG--
extra : rebase_source : 9ff275af226cfe65697b980d1b19f9ca9e1dad5f
We currently raise if we detect a command has both the `parser` attribute and a subcommand
at the same time, but as far as I can tell, there's no good reason to do this. Handling a
parser + subcommands seems to work exactly how you would expect. Furthermore, it isn't an
error to have subcommands + @CommandArgument, so it doesn't make sense that we're allowing
one but not the other.
This change solves an (admittedly unique) use case I'm trying to build into |mach try|. There
are N subcommands that all support a --save and --load style argument. So, e.g, we might have:
./mach try syntax --save foo
./mach try fuzzy --save bar
The main command will have the ability to detect which subcommand a saved value was generated
from and automatically dispatch to it. So this will work:
./mach try --load foo # dispatches to the syntax subcommand
./mach try --load bar # dispatches to the fuzzy subcommand
In order to share the --save/--load arguments across the main command + subcommands, we need
to set the parser attribute.
MozReview-Commit-ID: KmXRj8TBvYK
--HG--
extra : rebase_source : cbf1e402a080913709a34430274ae3191821dd72
Conceptually, a repaint request that arrives in APZCCallbackHelper with
!GetScrollOffsetUpdated() is a repaint request that the APZ is sending in
response to a main-thread update it received. The purpose of the repaint
request is mainly to update the displayport margins; the scroll position
and resolution should not have changed. Therefore actively trying to set
the scroll position or resolution as a result of these repaint requests
should at best be a no-op but often triggers unnecessary clobbering of things
that are in-flight, or extra reflows. This can result in buggy behaviour.
Bug 1286179 avoided doing this for the scroll position, and this patch does
the equivalent thing for zooming.
MozReview-Commit-ID: 91RbRP0ZHBe
--HG--
extra : rebase_source : 7bb97075619f5435705d369a695d37aa1c972278
This mostly prevents Gaol/sandboxing to be used during compilation.
There are a number of issues with : `expat-sys`, `servo-freetype-sys`, `fontsan`, `heartbeats-simple-sys`, `mozjs_sys`.
Also modified `components/script/dom/navigatorinfo.rs` in order to add iOS.
```rust
#[cfg(target_os = "ios")]
pub fn Platform() -> DOMString {
DOMString::from("iOS")
}
```
See here for more informations : https://github.com/servo/servo/issues/18154
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes partially work on #18154
- [X] These changes do not require tests because it deals with the compile toolchain
Source-Repo: https://github.com/servo/servo
Source-Revision: e61a043a567f2d8766b9bbecb88b3a9bfb7808d8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a2c0b7ec260e7fb45156d5d278abcd0a6b701e4c
In the event that many of these exceptions are thrown (which I witnessed
locally after importing a large number of desktop bookmarks), it could have a
negative impact on performance so we're making a fix. Note: we don't know how
much it happens in practice.
MozReview-Commit-ID: 1hQo7B704LV
--HG--
extra : rebase_source : b4dd1921b9886b8c403b6676fa9e49de5402b316
From version-control-tools revision
0451f128550d8c9dcf83d6628dea5a8030d5cc08. Vendored without
modifications.
This should be a rubber stamp review since the changes to
robustcheckout were already reviewed.
MozReview-Commit-ID: 3J0db7Cja1D
--HG--
extra : rebase_source : 4e36dc83a486841d253cd365ce7a6ceeb50a8ccc
This needs to be globally enabled to support sparse checkouts
and accessing repos using sparse checkouts.
Having the extension enabled should no-op unless sparse checkouts
are being used. i.e. it should be harmless to globally enable.
MozReview-Commit-ID: AKNUOXfYQPx
--HG--
extra : rebase_source : d32b8a89c56c39923d7b0cd61583c2828a29a872
Sparse checkouts may not have all mach_commands.py files.
mach raises an error when a mach_commands.py file is missing.
So, we teach the mach driver to ignore missing file errors when
a sparse checkout is present.
The added code is optimized to avoid an import of mozversioncontrol
and some I/O as part of resolving the repo and VCS binaries because
this file is in the critical path of all mach commands and avoiding
I/O is worthwhile. Since we aren't using sparse checkouts in the
common case, this effectively makes the new code 0 cost.
MozReview-Commit-ID: C6itJga31t5
--HG--
extra : rebase_source : 4b2c18d30ff8b923a940c80ac81372a4076b8fdc
This will facilitate handling this error condition specially.
Some unused imports were also removed.
MozReview-Commit-ID: 4zxVDgE7NxU
--HG--
extra : rebase_source : c4d0dd96629e028ce8a83215564a8d865e4b4b3d
This shouldn't be at module level.
This isn't technically needed for this series. I caught it during
an earlier attempt at teasing out all Python import dependencies
to run `mach`. Why let a good patch go to waste.
MozReview-Commit-ID: FwwdZqcKtpq
--HG--
extra : rebase_source : a8ce2cf452dc8c03371dc384ea4f1be9195b5d30