Allow to override Gtk+ theme for content process when e10s is enabled.
MozReview-Commit-ID: 1Kd2jLpBavA
--HG--
extra : rebase_source : b45171954ed9168e9d46511d53800044d91e5558
Due to Windows doesn't support dnd in the pen message handler, we can't handle and consume WM_POINTER* to fire WidgetMouseEvent. On the other hand, we can't get some pen related attributes from Windows mouse messages. This patch gets and caches the attributes by handling WM_POINTER* but not fire WidgetMouseEvent to support dnd and pen related attributes. When handling the subsequent Windows mouse messages, we use the cached attributes to fire WidgetMouseEvent. Considering we might need to use WM_POINTER* someday, use a preference to control the behavior.
MozReview-Commit-ID: 5E60KO1zo0W
Supports creating a windowless browser on Linux without an X server. Most of the
changes are just adding branches to avoid calls in to GTK which calls
into X. Some of the bigger additions were adding a separate headless widget
which implements just enough to render a page. A headless look and
feel were also added since there are many calls into GTK in the platform
specific one.
Add two new prefs (widget.chrome.allow-gtk-dark-theme and widget.content.allow-gtk-dark-theme) to enable dark
themes in chrome and content when e10s is enabled.
When e10s is disabled then widget.chrome.allow-gtk-dark-theme controls both chrome and web content settings.
That may be a bit confusing but it's going to be here for two releases only (Firefox 57 is going to have e10s enabled by default) and actually matches recent state when only one ENV pref is used for both chrome and web content.
The existing MOZ_ALLOW_GTK_DARK_THEME environment variable is still considered, but, now is like widget.chrome.allow-gtk-dark-theme, no longer affecting separate content processes.
MozReview-Commit-ID: CCwriA66CNj
--HG--
extra : rebase_source : 93e9a504af3e7570f82ddaf0890e374fe939e919
These defines cause include ordering issues that can result in build errors if
WinMessages.h is included before certain Windows headers.
To solve this issue this commit simply removes those defines since nowadays we
require Visua Studio 2015 to build and no longer need them.
MozReview-Commit-ID: GHMU05GUwHM
--HG--
extra : rebase_source : fcaadb93be6ff43f36ba98f164018d93c98a4e22
Needed because LogLevel is in the 'mozilla' namespace, but this file uses it
without qualification.
MozReview-Commit-ID: 5o2KV1GlcqM
--HG--
extra : rebase_source : 2b6bb2b6a6b0464b9c01c055101b23373d386c0f
We need the definition of CompositorWidgetDelegate in order to use
mCompositorWidgetDelegate.
MozReview-Commit-ID: Gr5G0SvCckk
--HG--
extra : rebase_source : 17db54c13bebb97c2d39e2dc0b69b7ad28346385
It looks like Google decided to split these jars out a bit, so we need to piece
them all back together.
We could probably just query the sdk version instead, but I'm not 100% sure
know when this setup changed - moreover we don't know when (if?) the paths
are likely to change again. SDK 26.0 still has lint 25.3.1, so the SDK and
lint versions don't appear to be tied.
It seems that only the lint* jars are needed to compile 'build/annotationProcessor',
however we need all the remaining jars in the classpath when running that code
in 'widget/android/bindings'.
MozReview-Commit-ID: GAKwMrVXW55
--HG--
extra : rebase_source : 4e790aaccae8ccc3f151c39bf1ef4404b2581d7a
There are scenarios where we have a TabParent in the UI process hooked up to
a PuppetWidget with a BasicLayerManager. Webextensions fall into this category.
In this scenario, the parent-side layer manager is not hooked up to
the compositor (that is, there is no entry in the CompositorBridge layer tree
state map for the layers id). However, the content-side still ends up creating
a ClientLayerManager or a WebRenderLayerManager, which expects the layers id to
be registered in the compositor. This results in brokenness (in the case of the
ClientLayerManager/PLayerTransaction) or crashes (in the case of WebRenderLayerManager/
PWebRenderBridge). Instead, this patch changes this scenario to have the content
process use a BasicLayerManager which seems safer.
MozReview-Commit-ID: 3f80aZrRrmD
--HG--
extra : rebase_source : 10ec78dd7daf1c1c889929f0d79e0b75675b4b05
GetScreenBounds() is slow for the GTK port so we override and use
mBounds directly in nsWindow::GetWidgetScreen()
MozReview-Commit-ID: ICElOCEzswf
--HG--
extra : rebase_source : 2fb450cc9d933346cebfdbff0b32ea4130550395
It is unnecessary to use Vista/7+ API via GetProcAddress
MozReview-Commit-ID: ELxCJev2jaZ
--HG--
extra : rebase_source : e1207ce5416d603090bd572ba745a703dadd93bf
I suspect that the PuppetWidget is trying to create the layer manager after
it has been connected to a TabChild but before the TabChild has populated the
CompositorOptions. This results in the PuppetWidget effectively getting an
uninitialized value for the CompositorOptions, and so it sometimes randomly
creates a WebRenderLayerManager, later resulting in a crash.
It seems like exposing the potentially-uninitialized CompositorOptions from
TabChild like this is a bad idea, so I'm removing that API and using the more
reliable gfxVars in PuppetWidget. This is fine for WebRender purposes because
we no longer care to allow having WR compositors co-exist with non-WR
compositors.
We may eventually want to remove the CompositorOptions entirely, but for now
the rest of the usage of it seems fine.
MozReview-Commit-ID: 6ekG8j1PskK
--HG--
extra : rebase_source : 0099e847ac356ca235969bcd81f47d65f49de2eb
