<!-- Please describe your changes on the following line: -->
This uses `kmerge` from itertools to construct the jsh future and past iterators without having to do a collect/sort. This allows us to reduce cloning of `FrameState`.
---
<!-- 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
- [X] These changes do not require tests because refactoring
<!-- 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: c87d0c671c2ae20a97099f3f369e81eb0ce5e403
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 43070ae1b6bc62aa2af1f0e07c74688a841b11e2
If the activity is restoring, onTabChanged might not be called.
To update title from existing Tab data in onResume.
MozReview-Commit-ID: 3LqQ6HDh7Dc
--HG--
extra : rebase_source : 1dd49658642be420d54d6a8e2d8c33e7658b0f2e
Now we can get toolbar color from intent directly, and the intent will
be stored in `onSavedInstanceState`. Let's get rid of the local
variable.
MozReview-Commit-ID: OsqwgFJctH
--HG--
extra : rebase_source : a5cd688de88de564739481f77fe514bdeffd6c0e
`getIntent()` not always returns the intent whith start this Activity
due to GeckoApp.onCreate reset it. We make a copy here in case of this
activity is destroyed and re-created.
MozReview-Commit-ID: 7TF3b1WdbM2
--HG--
extra : rebase_source : 60bab715166fd01b1fc89ca149e7f5a0f94e6bd1
When a subprocess is launched, gfxVars updates (for non-default values) are
serialized and passed on the command line, up to a limit of 1023 characters,
and ensuring it should not overflow the command line size.
When the child starts, the command line parameter is given to gfxVars, so the
updates can be used during gfxVars::Initialize(), instead of doing a sync
request to the parent.
In case the updates are not sent, or in the unlikely case the child cannot
parse them, we fallback to the sync request -- The former case should be rare
enough that a slow sync request is acceptable: It should only happen if D3D
block-list is *modified* (most people would either use the default, or just
overwrite these prefs with short strings.)
MozReview-Commit-ID: 6MoJC0fe59Q
--HG--
extra : rebase_source : cdc2e451783160c579b8fc84050e8457c600523e
<!-- Please describe your changes on the following line: -->
This is a PR of https://bugzilla.mozilla.org/show_bug.cgi?id=1336668
---
<!-- 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
<!-- Either: -->
- [X] These changes do not require tests because there is a test case in web-platform-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: 8c2548a0c479d42dbc68ec1b64d028dcf5643dd5
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : b26ac73a5425326c63491afe2e83f8471a44211a
They have generic names, and are potentially conflicting with
in-tree headers with the same name (which is true for at least port.h).
There aren't enough users of brotli to want to avoid LOCAL_INCLUDES
in the directories that use it.
--HG--
extra : rebase_source : 82531ac5961ad80e1b3d0c1484a2f146be194411
woff_out.h includes port.h (actually, worse, "./port.h"), and in
dist/include, port.h is actually *not* the one from woff2...
We've just been lucky it's worked so far.
--HG--
extra : rebase_source : 65537c1f6c0ba540e0c93ef2c8ba587e5903d273
The current mechanism requires threading a lot of this state through a bunch of
callsites that are several layers of abstraction above the code that actually
uses this vector (which is only compiled for servo). Putting it in
CurrentElementInfo gets it nicely out of the way.
Source-Repo: https://github.com/servo/servo
Source-Revision: 48a412abc7d56529770bdbe2cf0f5e6af852538e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 0835e398d3db3ff28992d71ee648485033c3c94d
This patch does the following in addition to a simple move:
* change the type of the pointers from RefPtr to nsCOMPtr
* move it from mozilla::css namespace to mozilla
MozReview-Commit-ID: 72MYq6kWm4s
--HG--
extra : rebase_source : 400fe0d7cc422f22592c302cfd4e457830b77e3e
This is the Servo side change of [bug 1343964](https://bugzilla.mozilla.org/show_bug.cgi?id=1343964) which has been reviewed on Bugzilla.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9ad95a5dc74455c52233963fba4fb31324c40847
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2d135f6e480fc2e1ff0b820ec4c4211465de5415
This only has overhead if the profiler is running, but it means that it has
the potential to skew restyle times in profiles.
We haven't measured the overhead of this, but it's probably non-zero, and at
the moment our profiling efforts are more focused on getting accurate times
than on getting useful information about restyling cost sources.
MozReview-Commit-ID: 3KmiiyGrxZH
--HG--
extra : rebase_source : df7047f1af5f36f7a1b3a18498d8eb5508ee0b93
Testing the return value is misleading in this case. What we want to
test is that it does not throw due to a permissions issue.
MozReview-Commit-ID: 2Wbwou9opyF
--HG--
extra : rebase_source : cd056ed38b9cf7b9eb095635209fbe6b090721fd
The Components.classes constructor should throw an error in both the
mutable and the "default" sandbox.
MozReview-Commit-ID: C40nZNaVWwz
--HG--
extra : rebase_source : f02506f16ff409761ba09ae0f32ff2902cdf07a3
We accidentally only ran them in "default" and "system" before, and also
one of the arguments in the system globals test was wrong.
MozReview-Commit-ID: DmBYGsZaIVP
--HG--
extra : rebase_source : c9f1493ce3faed0ec2e5ad6125a4f7811a1fef03
We were previously missing a test for the arguments variable that is
implicitly exposed to functions.
MozReview-Commit-ID: IC6aJcUsyhd
--HG--
extra : rebase_source : 9039dcb7fcea681d8c9cd729cca8c55701631a5c
The Python standard library uses tuples to define arguments for functions,
whenever they are invoked through meta programming.
The Marionette client only allows the list type for backwards
compatibility, so we prefer tuples in this case.
Another good argument for tuples is that tuples are immutable.
MozReview-Commit-ID: 72zPzYvBz7Q
--HG--
extra : rebase_source : 2406e92b8bec8a965df6457bb166fd9761513b1e
Marionette does not protect the unloadHandler in
testing/marionette/evaluate.js from content introspection or
modification, which can happen when web frameworks override
window.addEventListener/window.removeEventListener.
The script evaluation module used in Marionette relies on
sandbox.window.addEventListener/removeEventListener to throw an error when
script execution is aborted due to the document unloading itself. If the
window.addEventListener/removeEventListener functions have been overridden
to introspect the objects that are passed, they may inadvertently touch
objects originating from chrome space, such as the unloadHandler.
Because the Gecko sandboxing system put in place strict security measures
to prevent accidental chrome-space modification from content, inspecting
the unloadHandler will throw a permission denied error once the script
has finished executing.
We have found examples in the wild of this in particular with the Angular
web framework. This patch makes the unloadHandler safe for introspection
from web content.
Fixes: https://github.com/mozilla/geckodriver/issues/515
MozReview-Commit-ID: E2LgPhLLuDT
--HG--
extra : rebase_source : 6fe4f61fd18f42fb5332a664189f3ea919db28c5
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : 071a9cb1769f013717357458df24e2fd9570ccf4
When we're animating, we tick the refresh driver. If that occurs in the parent process
when e10s is enabled, then we currently run TabParent::DidRefresh which does some
dimensions calculations and might send a message to the content process if the
dimensions have changed.
This was originally added to fix a B2G bug in bug 1153023. We don't need to do it
anymore, since we don't set CSS transforms on content browser windows.
MozReview-Commit-ID: JJ7AJHlSyWn
--HG--
extra : rebase_source : b45c9f02c3db8b7ecf0beb40fa7540db39473e8d
These directories contain sensitive content, and access is not necessary now that we have file content processes.
r=haik
MozReview-Commit-ID: FiRJkMnlYUx
--HG--
extra : rebase_source : 0bcdefcb1ea410fb26c3f8373673488e2a5fdd75
This is a pretty straightforward change. Just bumping package versions
and hashes. Behavior should be almost identical to the previous 4.1.1+
packages.
MozReview-Commit-ID: CaVjM0JHYKi
--HG--
extra : rebase_source : dcd0ee2661fd088daf3b5c6709c4c6f2f95bd410
The gecko messages are now in the "process_output" action, rather than
in the "log" action (except for a few legacy cases), so examine both
when looking for LSAN messages.
MozReview-Commit-ID: 82r1p8WLwFa
--HG--
extra : rebase_source : 5af1c529e58f5ba90a3fd222e3cbbc67a850a08c
These variables are ignored in favour or reading the same values
from the passed in libdef object.
MozReview-Commit-ID: 8Xkkd68clNN
--HG--
extra : rebase_source : 767c15f1b59a6f48d09411c4f2e64eff9f8b4cc6