Note that this dynamic change will not work without a patch for bug 1478576
if user doesn't touch browser windows.
Differential Revision: https://phabricator.services.mozilla.com/D3301
Now nsBaseWidget::NotifyThemeChanged properly notifies to the pres shell.
MozReview-Commit-ID: Kmd68ckHanl
--HG--
extra : rebase_source : 9928f3788f34b05ff91d1d2b11e2cd332f00af76
Even with this patch, the setting change doesn't affect media queries in sub
frames due to bug 1478212. But the bug is a pre-existing issue, for example
system color settings don't affect contents in sub frames either. So we can
land this patch as it is.
Note that there is no way to write an automation test for this unfortunately.
MozReview-Commit-ID: L2Knhp1IjrU
--HG--
extra : rebase_source : 3487a13d0466b68419e55610c8ce3e384df28e64
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
Some odd mouse drivers try to activate a window which the mouse driver wants to
scroll its content (such window is typically under the mouse cursor when mouse
wheel is turned). However, this is illegal behavior and such odd mouse drivers
try to activate our popup windows which won't be activated without such apps.
We prevented this odd focus behavior with fixing of bug 953146. However, it
did NOT stop notifying widget listener of activating nor inactivating the
windows. Therefore, that caused a lot of reflow for supporting
-moz-window-inactive pseudo class.
This patch makes nsWindow::DealWithPopups() consume WM_ACTIVATE message before
nsWindow::ProcessMessage() because nsWindow::ProcessMessage() notifies widget
listener of activating and inactivating window even when focus move from and to
our popup window. So, in other words, this patch stops notifying widget
listener of activating and inactivating window when focus moves from/to
a popup window.
MozReview-Commit-ID: 2dyq07zHZKp
--HG--
extra : rebase_source : 8075a3ead73a5f2892a1a1a8e71252e574200bf4
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
Currently, TabChild discards eKeyDown and eKeyPress events which are marked as
"repeated" and were dispatched after the latest eKeyDown event comes into the
process. However, keyboard layout utils may generate native key events
as "repeated" even if each native key is important to input proper text.
So, TabChild shouldn't decide if coming keyboard event is skippable only with
mIsRepeat. For solving this issue, this patch adds
mMaybeSkippableInRemoteProcess to WidgetKeyboardEvent and makes
TabChild::SkipRepeatedKeyEvent() check
WidgetKeyboardEvent::CanSkipInRemoteProcess() instead.
On Windows, there are two ways to generate keyboard input messages. One is
using SendMessage() or PostMessage(). The other is SendInput() API. In both
ways, utils can make their input as repeated key messages.
The former case must be safe for this issue since such utils need to set 31st
bit of lParam to 1 explicitly.
On the other hand, in the latter case, the utils probably need to append
KEYEVENTF_KEYUP into KEYBDINPUT::dwFlags. Otherwise, only first call is
treated as non-repeated event.
So, when given message does not came from physical key operation, NativeKey
should set WidgetKeyboardEvent::mMaybeSkippableInRemoteProcess to false
even if WidgetKeyboardEvent::mIsRepeat is true.
MozReview-Commit-ID: 3rinrOjx8Tf
--HG--
extra : rebase_source : 26b6d869260176fc7ef535323b83001bb4b725c2
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : 59e4a6ced7d14d2a01c0b79e944078ea84cae523
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
The clip chain API in webrender allows us to build the clip state in WR
so that it matches the gecko display list more closely. This patch throws
away ScrollingLayersHelper.* and introduces ClipManager.* which pushes
the clip state to WR using the new method. A quick summary of the new
method is below.
Each display item in gecko has a DisplayItemClipChain which is a chain
of individual clips. The individual clips are defined in WR, and the
clip ids for those clips are put into a WR clip chain using the new
define_clip_chain API. Furthermore, each clip chain can also have a
parent chain, which is used to link a DisplayItemClipChain to the parent
display item's DisplayItemClipChain. This allows the WR clip state to
closely match the structure of the gecko display list clip state,
resulting in more correct behaviour.
There are a few other major changes that are lumped into this patch and
that were tricky to separate into their own patches:
- The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR
side all the clip ids are treated the same anyway. Trying to preserve
the arbitrary distinction on the gecko side was resulting in
increasingly convoluted code, with different kinds of Variant<..>
types in the method signatures. It was much simpler and resulted in a
bunch of code deletion to just collapse the types.
- Moving the "override" mechanism from WebRenderAPI to ClipManager. The
override mechanism (explained in ClipManager.h) was simplified by
moving it into ClipManager, because it removed the need for tracking
additional clip stack state in WebRenderAPI.
MozReview-Commit-ID: GGbdFyJGprK
--HG--
extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
Mostly just convert nsInt{Rect,Region} to LayoutDeviceInt{Rect,Region}.
One exception is to change the parameter of nsWindow::OnResize from
nsIntRect to LayoutDeviceIntSize, because it really only needs that.
MozReview-Commit-ID: 963Mzd5Wed6
--HG--
extra : rebase_source : efae039d26feb98a3591a7cd46c30ce4f052d70b
Windows default behavior will trigger the System menu bar when F10 is released.
Among other things, this causes the System menu bar to appear when a web page overrides the contextmenu event.
We *never* want this default behavior, so eat this key (never pass it to Windows).
MozReview-Commit-ID: 4fWOuj4mWvW
--HG--
extra : rebase_source : 45d38ba19b2f23aca74a60819c7d93af2ffa167d
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
We will create several new files in the following patches for IPC and a new
subprocess. Several already existed files will be shifted into new build units,
we will meet several compile errors because of it.
This patch fixes those compile error in advance.
MozReview-Commit-ID: 5hd0sNYfBu0
--HG--
extra : rebase_source : d4cca529623586188ffebffd858f53188d12bb50
We will create several new files in the following patches for IPC and a new
subprocess. Several already existed files will be shifted into new build units,
we will meet several compile errors because of it.
This patch fixes those compile error in advance.
MozReview-Commit-ID: 5hd0sNYfBu0
--HG--
extra : rebase_source : 0d85c823e4ead4f09175f2cc83df811b2b4081ec
