"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.
Before bug 1413181, HTMLEditRules::SplitMailCites() receives left node of
split node with |leftCite| from SplitNodeDeep(). However, the out argument
was removed by the bug and now, it can be retrieved with
SplitNodeResult::GetPreviousNode(). Its result is used for creating <br>
element etc, but not set to |leftCite| but HTMLEditRules::SplitMailCites()
still checks if |leftCite| is empty to remove it from the DOM tree.
So, now, both |leftCite| and |rightCite| are not necessary and
HTMLEditRules::SplitMailCites() should use |previousNodeOfSplitPoint|
instead of |leftCite|.
MozReview-Commit-ID: 408MJt6X1IV
--HG--
extra : rebase_source : fa6095ccc972d33afe8deb0f124adffea7371f4e
To correctly apply pixel snapping during display list construction we would need to snap each tile of a repeated gradient individually. It's preferrable to do this in WebRender rather than decompose gradients into many display items.
Now we're loading the sizemode attribute earlier, doing this on load stops
working.
MozReview-Commit-ID: ToiJiYrvFw
--HG--
extra : rebase_source : 48ad80e5535ecc5f7c8c8297f417f797deddc017
extra : source : 80194b5bf0e7bbcccf727d2fec140e747ebd0949
extra : histedit_source : 2b7755fece2a564fc806369280559c8829d3d486
To avoid hacking around the empty window, and handle the activation issue seen
on Windows / OSX.
MozReview-Commit-ID: oK3T8FKd5n
--HG--
extra : rebase_source : 4d1ed1bae673b3b0e533d7c66303a3cf995fda8b
extra : source : 461021b4bf3ab189babba096584682b2469ce9df
extra : histedit_source : eaa97d93bb4e100e1410471b19585ac125bd828d
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
--HG--
extra : rebase_source : 253bea4c4e90727c0e8cce4726bf7a695ca26d9d
extra : source : 4d6f855ea529f6043b3ca886f53901e16a3d6405
extra : histedit_source : b0aa76063dca7a85e43b3bf670aab8f185a57915%2C760885a660c4fd92e7ae777614ad3cdc84dc9b31
The only subtle thing is the mCenterAfterLoad stuff, which is gated after a
mChromeLoaded.
Other than that it follows the same pattern as bug 345560.
MozReview-Commit-ID: 8qDiA2yn9DB
--HG--
extra : rebase_source : 8ad309e3f449cea1536bfbff8e8b1585fefbc186
extra : source : f582644f846cee16b554d694d24b4eb8ca3c5106
This policy disables the safe-mode UI entry points. In addition, only on Windows when using GPO, it also disables entering Safe Mode by holding down the Shift Key
When we swap <browser> frameloaders, the message managers on the parent side
also change. And since a frameloader swap is usually followed by the original
<browser> and its message manager being destroyed, this leads us to think the
message manager has disconnected earlier than it actually does.
MozReview-Commit-ID: LC9aaoynWzH
--HG--
extra : rebase_source : 7fdcd78d12bad8898a6219ee799f64e15427e189
