This adds workarounds to ensure that messages passed from browser.js
to content.js in the context of certerror pages always contain a frameId
which can be used to identify the frame that is supposed to receive them.
This fix is really meant to be temporary until we come up with a good
replacement for chrome - content communication, which probably boils down
to finding a middle ground between nsAboutCapabilities, RemotePageManager and WebChannel.
I did not update communication for Captive Portal pages, since those require
one-way broadcasting from chrome to content, which is not supported in this model.
This is tracked in bug 1446319.
I did also not change the behavior of the "Go Back" button, which still navigates
away the top level page, because I consider changing that behavior out of scope
for this bug (and in my personal opinion we should not change the behavior).
MozReview-Commit-ID: GrM6PFys6Cu
--HG--
extra : rebase_source : 5a49571b04b682bcde61e61f9874a25e405661f5
This amends the browser_aboutCertError test file to cover error pages
in iframes in addition to top-level pages. I figured that instead of
re-writing all assertions in a separate test it would be smarter to
do the same assertions we apply to the top-level error pages on frames
as well.
I did not update the checkWrongSystemTimeWarning test, which is currently disabled.
MozReview-Commit-ID: 90fS0emPaSN
--HG--
extra : rebase_source : 90390afd294cb7254ff3c8249fa84a43ad6a517d
Try to comprehend exactly how the original test worked... I dare you!
MozReview-Commit-ID: 5EYOfhw3hVw
--HG--
extra : rebase_source : 4b5a7eb5f16c8ad1d0cca3f4642a87108b9da913
browser_storage_listings.js doesn't use CPOWs and runs just fine with the flag removed.
I would r=me this if ReviewBoard would let me but I can't.
MozReview-Commit-ID: IHoY7qLR3k2
--HG--
extra : rebase_source : 7aa0d5111307e453b1bf17a8433d9b86d8424f73
Most of the classes in xpt.py define a helper method to encode the
values of the flags into a byte, but for some reason Method does
not. It'll be useful to have one for Method for the C++ backend I am
working on.
MozReview-Commit-ID: ESi1CnstbN2
--HG--
extra : rebase_source : 23822e7770e9a3d1b5a2359ae9753f950af3a121
Replace the boolean pref "security.sandbox.mac.flash.enabled"
with "dom.ipc.plugins.sandbox-level.flash" to support sandbox
levels and be consistent with the Windows pref name.
Adds filesystem read access to the sandbox using sandbox extensions
granted by the file dialog machinery (level 1).
Add support for level 2 which blocks read access.
Allow the sandbox to be disabled with MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 4rfobEoxQpF
--HG--
extra : rebase_source : 05dc54b46063967e959bc3fced21c61e5463de48
Adds additional sysctls that are used by the Flash plugin process and alphabetize the list.
MozReview-Commit-ID: 7CaPtaKe874
--HG--
extra : rebase_source : 909228ef9617029eaf7cb16565751150cd1c7404
Remove access to DARWIN_USER_CACHE_DIR. Limit DARWIN_USER_TEMP_DIR
access to the FlashTmp subdirectory. Remove xattr read access to
~/Library/Caches/ and ~/Library/Preferences.
MozReview-Commit-ID: 9svk0BoxVXs
--HG--
extra : rebase_source : 5ea9c7ecc0189455eceb190fb300170d42d0b890
In the fonts panel UI prior to Firefox 60, remote font URLs used to be
displayed in full in a text input field. It made it easy to copy them.
With the redesign that happened in 60 (bug 1437548 and 1442001), getting
the URL became harder. The URL isn't visible anymore easily. There's a link
that can be clicked to load the URL in the browser, or it can also be copied
from the @font-face CSS rule code section. But that's harder.
This change adds the beginning of the URL back (with an ellipsis) and a
simple button that copies the link.
MozReview-Commit-ID: 2oSMoWKYhTk
--HG--
extra : rebase_source : 1af901f4a343f392b65309fde34411313606b824
"unqualified friend declaration referring to type outside of the nearest enclosing
namespace is a Microsoft extension; add a nested name specifier
[-Wmicrosoft-unqualified-friend]"
This pref was introduced in case we encountered compatibility issues from
changing the return value of Animation.playState (bug 1412765). Now that the
change to Animation.playState has shipped to release channel without any known
problems we should drop this pref.
MozReview-Commit-ID: CwMWRRtIf6u
--HG--
extra : rebase_source : b26c59a51880406c2b94baad8da2eafeb3ae3202
<!-- Please describe your changes on the following line: -->
When the options are set not from the command line but by calling `set_defaults()` which is common for embedders, the MULTIPROCESS static is not set, and so the setting is ignored. This patch fixes that.
---
<!-- 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 we have no tests around that.
<!-- 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: b93f153ed59fb993af306bd8c540887196021f87
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6c85e2e3c9e0ef460304606c14edc356bdd721af
A couple of RemoteContentController methods get called on the controller
thread in the GPU process. This is the same as the compositor thread so
we could just do compositor-thread stuff here, but we will want to
support the controller thread being the main thread instead of the
compositor thread. So we detect those cases and bounce the message
accordingly.
Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
Without this patch, UpdateZoomConstraints can get called on:
a) the compositor/sampler thread (over PAPZCTreeManager)
b) the controller thread which is also the UI process main thread (on
desktop platforms without a GPU process)
c) the UI process main thread when it's *not* the controller thread (on
Android).
Instead of having to reason about all these scenarios separately, we can
try to unify them a little bit by ensuring the function contents always
run on the sampler thread, which is the thread that seems to make the
most sense for it.
These two functions (UpdateWheelTransaction and ProcessUnhandledEvent)
are only ever called on the concrete APZCTreeManager when the APZ code
is living in the GPU process. This is because the calls are made by the
IAPZCTreeManager implementation which lives in the UI process, and
remoted over PAPZCTreeManager. So the assertion is safe, and will help
us guard against inadvertent breakage when we try making a different
thread the controller thread in the GPU process.
In addition, the WillHandleInput function can be called in the GPU
process on the compositor thread, but we will allow it to be called on
the main thread as well. In that case we need to ensure we don't try
running EventStateManager pref-reading code in the GPU process, and
instead preserve the current behaviour of just returning true.
This function is never actually called over IPDL. It is called directly
on the concrete APZCTreeManager instance by the
AndroidDynamicToolbarAnimator code, both of which live in the
compositor. So we don't need to expose this method on IAPZCTreeManager
or over PAPZCTreeManager.
Since we can have multiple browser windows on multiple different
displays with different DPIs, it doesn't make sense to have a single
static DPI value shared across all APZCTreeManagers. Instead, each
APZCTM should store its own DPI value for the display the window is on.
Since the DPI is only ever read from the controller thread, we can make
it bound to that thread, and update the setter code to also set it on
that thread.
As with the previous patch, the change in APZCTreeManagerParent is a
no-op but allows making some other thread in the GPU process the controller
thread. And the change in nsBaseWidget is a no-op everywhere except
Android.
- The change in APZCTreeManagerParent is functionally a no-op because it
only ever runs in the GPU process on the controller thread. But it
allows moving the controller thread to some other thread.
- The change in nsBaseWidget is a no-op for desktop platforms, because
in the UI process the main thread is the controller thread. But on
Android it moves the call from the main thread to the Java UI thread.
Vivek Dhingra
Johann Hofmann
Michael Ratcliffe
Andrew McCreight
Johan Lorenzo
Sylvestre Ledru
Zibi Braniecki
Csoregi Natalia
Kartikaya Gupta
Haik Aftandilian
Sebastian Hengst
Carl Corcoran
Patrick Brosset
Dão Gottwald
yulia
Andreas Pehrson
Tiberius Oros
Gurzau Raul
Jeff Gilbert
Thomas Daede
Brian Birtles
Fabrice Desré
Brindusan Cristian
Monty Montgomery
Kris Maglione