The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
This copies over the early-exit conditions from MaybeDrawTitlebar which
is the non-WR codepath where this gets drawn. In particular, the
!mIsCoveringTitlebar clause is true when the titlebar is enabled.
MozReview-Commit-ID: 6B7vKYuyrRP
--HG--
extra : rebase_source : b8f73d2c4f9e582bdb018e6aa121e92d54c60334
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
--HG--
extra : rebase_source : b66bf6427db5be2eb12f4e0aa36d22a4da46555a
This is generally helpful. I'm also seeing much less than 50% of the
wrQualified people in the study getting webrender so this could help
determine why.
MozReview-Commit-ID: 2neTFBytzPz
--HG--
extra : rebase_source : 97b1b1fe80f1a2c574141eaef8ad23499699fb82
The constructor of WidgetCommandEvent takes 2 nsAtom pointers. One is for
specifying event type, the other is for specifying the command. The
difference of these arguments are pretty unclear for other developers and
the former argument is always nsGkAtoms::onAppCommand unless nullptr in
C++ code. So, we can hide the former argument.
Then, we should create another constructor for creating empty command event
from constructor of dom::CommandEvent.
Differential Revision: https://phabricator.services.mozilla.com/D2506
--HG--
extra : moz-landing-system : lando
When resuming composition in a new GeckoView, we wait for the first
paint signal in order to uncover the SurfaceView. This patch makes sure
that we always send the first paint signal.
MozReview-Commit-ID: EZeOR80d8HY
--HG--
extra : rebase_source : f82ab94ef87e5b0651f368918e8cd8a97469c68e
Make sure the window XID is propagated to X server, we can fail otherwise
in GPU process.
MozReview-Commit-ID: BMkLvhs4vRt
--HG--
extra : rebase_source : 34269cbf7e088fd15c090f3abc8ee2d46da307c4
IME (e.g., fcitx) may refer selection colors of widget under window which
is associated with IM context to support any colored widget. So, IME
expects good selection colors which have sufficient contrast between
foreground and background, and also selection background color and
widget background color like GtkTextView. However, some desktop themes
set our widget to different selection colors from GtkTextView which may
be unreadable.
nsTextFrame (which paints composition string) expects that composition
string colors coming from IME are sufficiently readable and background
color of composition string and background color of our editor's default
style (coming from LookAndFeel) have sufficient contrast because
nsTextFrame assmes that composition string colors coming from IME are
decided for the default style.
Therefore, this patch creates SelectionStyleProvider which overwrites
selection style of our widget with selection style of GtkTextView so
that IME can refer selection colors of GtkTextView via our widget.
MozReview-Commit-ID: 5vdcSgoEYv0
--HG--
extra : rebase_source : edf375ac393a72d3e44839a76d5c44b6db12dc63
This makes sure things work under e10s, but also results
in simplified code since we weren't actually using the
features of nsScreenManagerAndroid any more.
MozReview-Commit-ID: 1zghxZuLqr3
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
The patch at bug 1478391 comment 6 changed the way the math in Scrollbarbutton*
worked, which pretty surely caused this.
Restore the original order and math to be the same as before bug 1478391.
MozReview-Commit-ID: CK3iOqeX2NW
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
IsComposited() does not reflect Visual selected by GLContextGLX::FindVisual()
which is used by WebRender which leads to shaped window rendering with WebRender.
IsComposited() is replaced by mHasAlphaVisual variable which is explicitly
set when we have an alpha visual and we don't need to use shape X11 extension.
MozReview-Commit-ID: 1kDLwkUyHte
--HG--
extra : rebase_source : 3a60fe8fd66f9e89bfcc729fe5e1fa9e1ce8920d
Check for null TextComposition pointer, which can apparently happen
during regular usage.
MozReview-Commit-ID: 6nKjyBVL2vF
--HG--
extra : rebase_source : 68d8ff37612f6908b3983993fc73d19e9c0b0e50
Also remove mozilla.widget.use-argb-visuals which is useless since we don't allow transparent
toplevel windows.
MozReview-Commit-ID: 2ep3daeLZTG
--HG--
extra : rebase_source : 9ca5f2d0ded6dec1827caf2cb87e81fcb9b11792
Add a new config attribute to GtkCompositorWidgetInitData to allow transfer
the shape option from nsWindow. Also when shape is requested don't use XRender
or Shm widgets - only X11Image is supported now.
MozReview-Commit-ID: ElxnGQpLOry
--HG--
extra : rebase_source : 03552fc4103f6b22c512c07fe37102701998ed94
Derived routines for shape bitmap mask form nsWindow.cpp,
at WindowSurfaceX11Image we compose a final RGBA image and then create
the shape mask from image alpha channel.
Also the implementation is slightly simplified as it's meant as a fallback only.
MozReview-Commit-ID: 6VtGcsVKlcv
--HG--
extra : rebase_source : e8b96d68082ae687e376bc89c79f88f9c34cdc15
widget/windows/WinUtils.h is getting unwieldy and contains a combination of
both header-only and non-header-only code. I thought I'd take the opportunity
with this patch to create a new file for self-contained, header-only utility
functions, with the hope that we can eventually migrate some stuff out of
WinUtils into WinHeaderOnlyUtils in the future.
--HG--
extra : rebase_source : 6c874f78fc7113d1f7011fcd57ad9d024edb6761
aWidgetType is a NS_THEME_* constant. What this code is comparing is not.
This was exposed by a patch of mine converting -moz-appearance to be an enum
class.
MozReview-Commit-ID: 9BsbYk04vop
This patch fixes redrawing of the popup element by removing the scale factor
from the invalid regions because the wl_surface_damage multiplies it with the
scale factor too.
Also we set scaling factor of the wl_surface right after we create it to avoid
flickering when the compositor switches from unscaled to scaled surface.
MozReview-Commit-ID: 1eGoFu87wtF
--HG--
extra : rebase_source : 08abe86889e34865f3eed0f3979b4a584cc74adb
