CompositorWidgetChild is about to be responsible for creating,
destroying, and presenting a shared buffer that CompositorWidgetParent
will draw into. To do this, it will need the window handle,
transparency mode changes, window size changes, and window size mode
changes.
Its creation is also about to become fallible, so it needs a separate
initialization routine.
Differential Revision: https://phabricator.services.mozilla.com/D57430
--HG--
extra : moz-landing-system : lando
This is useful if you get a certificate-related error and want
to inspect the broken certificate.
Differential Revision: https://phabricator.services.mozilla.com/D58170
--HG--
extra : moz-landing-system : lando
This is the server certificate, if any, as a
java.security.cert.X509Certificate.
Differential Revision: https://phabricator.services.mozilla.com/D58156
--HG--
extra : moz-landing-system : lando
Since `XPCOMEventTarget` uses JNI, this patch makes it possible for consumers to
retrieve and invoke methods on one without needing to worry about whether JNI
is actually up yet.
To achieve this, we create the `IXPCOMEventTarget` interface, and observe that
both of its methods can be handled by a proxy if JNI is not ready:
* Calls to `dispatch` may be enqueued until JNI is up;
* Observe that, when JNI is not up yet, the result of `isOnCurrentThread`
can never be `true`.
Once JNI is up and the event targets have been resolved, the proxies are
replaced with the real, concrete `XPCOMEventTarget`s and are no longer used for
the remainder of the Gecko instance's lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D57837
--HG--
extra : moz-landing-system : lando
PlatformCompositorWidgetDelegate was meant to be a pure virtual base
class for all the functions that nsWindow could call that would
either go to an in-process compositor widget or an OMTC widget.
By that definition, it does not seem like CompositorWidgetParent should
be a subclass, since nsWindow cannot directly call its methods and
currently CompositorWidgetParent has several "do nothing"
implementations of the interface methods because they don't really
belong.
This changeset remedies this by refactoring CompositorWidgetParent so
it is no longer an implementor of PlatformCompositorWidgetDelegate. Now
the only implementors are CompositorWidgetChild and InProcessWin-
CompositorWidget, which makes sense because they are both directly
called through the nsWindow delegate.
It also eliminates some of the methods that seem like they don't belong
in PlatformCompositorWidgetDelegate.
Differential Revision: https://phabricator.services.mozilla.com/D57429
--HG--
extra : moz-landing-system : lando
This looks like a large change, but it's really just moving stuff
around.
It takes the logic in WinCompositorWidget and duplicates it into
its only 2 subclasses: InProcessWinCompositorWidget and
CompositorWidgetParent.
This is because CompositorWidgetParent is about to change *a lot*, but
InProcessWinCompositorWidget will basically stay the same. This is an
easy way to verify that I don't accidently break
InProcessWinCompositorWidget.
Differential Revision: https://phabricator.services.mozilla.com/D57428
--HG--
extra : moz-landing-system : lando
Using LookAndFeelInt to query system colors is awkward, it's normally used for
eIntID_XX values.
Differential Revision: https://phabricator.services.mozilla.com/D58744
--HG--
extra : moz-landing-system : lando
Once we start supporting different model IDs for different windows of the same
application we need to make sure that the normal windows have a model ID and
the jump lists and recent documents are tagged with the same ID. We do this by
always having an app default model ID, when no window specific model ID is set
the app default is used.
At some point we may want to extend the jump list stuff to support using a
different model ID but that isn't needed right now.
Differential Revision: https://phabricator.services.mozilla.com/D57152
--HG--
extra : moz-landing-system : lando
I did some cleanup while here: This now uses the callback's lParam
instead of a global, and does the enumeration of all windows only if
the foreground window doesn't already belong to this process (which
was proposed in bug 259816 comment 68 but didn't make it into the patch).
Differential Revision: https://phabricator.services.mozilla.com/D57922
--HG--
extra : moz-landing-system : lando
nsWindow::UpdateOpaqueRegion() is used from Main thread and it collides with
moz_container_get_wl_surface() where opaque region is used and which is called from Compositor thread.
As a fix don't set opaque region directly for mozcontainer but rather just use a flag to signalize
there's an update needed and calculare/set the opaque region at moz_container_get_wl_surface() or
moz_container_egl_window_set_size().
Differential Revision: https://phabricator.services.mozilla.com/D58840
--HG--
extra : moz-landing-system : lando
This looks like a large change, but it's really just moving stuff
around.
It takes the logic in WinCompositorWidget and duplicates it into
its only 2 subclasses: InProcessWinCompositorWidget and
CompositorWidgetParent.
This is because CompositorWidgetParent is about to change *a lot*, but
InProcessWinCompositorWidget will basically stay the same. This is an
easy way to verify that I don't accidently break
InProcessWinCompositorWidget.
Differential Revision: https://phabricator.services.mozilla.com/D57428
--HG--
extra : moz-landing-system : lando
The idle-inhibit protocol allows idle wake locks on Wayland
without any of the supported D-Bus interfaces running.
Differential Revision: https://phabricator.services.mozilla.com/D49095
--HG--
extra : moz-landing-system : lando
Showing a new notification with the same name of an existing notification
replaces the old notification so we must unregister it from Windows at that
point.
Differential Revision: https://phabricator.services.mozilla.com/D58270
--HG--
extra : moz-landing-system : lando
Other platforms send out the finished notification when the notification is
programmatically cancelled. This patch ensures that finished is always sent.
Differential Revision: https://phabricator.services.mozilla.com/D58269
--HG--
extra : moz-landing-system : lando
By making the IStream object free-threaded (or "agile"), IStream::Read will be
called off the main thread. So we can wait until favicon is created.
Depends on D56478
Differential Revision: https://phabricator.services.mozilla.com/D56479
--HG--
extra : moz-landing-system : lando
nsTouchBar.h/.mm were getting a bit unwieldy, particularly after the TouchBarInputBaseType enum from the next part of this patch was added. This part splits out TouchBarInput into its own files. This makes the Touch Bar's file structure similar to that of the menu bar's: nsMenuBarX, nsMenuBarItemX, and nsMenuBarItemIconX contrasted with nsTouchBar, nsTouchBarInput, and nsTouchBarInputIcon.
Differential Revision: https://phabricator.services.mozilla.com/D56589
--HG--
extra : moz-landing-system : lando
This allows GfxInfoX11 to get GLES3 and Mesa version from Wayland-EGL, which
allows automatic enablement of acceleration to work without Xwayland.
This also fixes bug 1578598 - WebRender did not work correctly
without this GL version information.
Differential Revision: https://phabricator.services.mozilla.com/D57474
--HG--
extra : moz-landing-system : lando
Over in bug 1604761 I realized that GTK has a high-contrast accessibility
setting, that GTK does not honor the same way as windows does.
There's no good reason for that IMO, and high contrast mode on windows is
getting some love.
This hooks the relevant parts of the GTK widget code so that we also avoid
websites overriding high contrast colors (via PreferenceStyleSheet and co).
Differential Revision: https://phabricator.services.mozilla.com/D58278
--HG--
extra : moz-landing-system : lando
Calculate and set correct opaque regions for all wl_surfaces, which are:
- mShell - toplevel window with CSD decorations, opaque mask needs to be shifted by titlebar/CSD size and subtracted transparent corners.
- mContainer - child window with subtracted transparent corners.
Differential Revision: https://phabricator.services.mozilla.com/D57797
--HG--
extra : moz-landing-system : lando
On macOS 10.12.1+, we use `MediaPlayer` library, which has better media key integration, to replace the implementation of `CG EventLoop`.
Differential Revision: https://phabricator.services.mozilla.com/D46890
--HG--
extra : moz-landing-system : lando
This makes it more similar to how SwapBuffers was used.
This patch also makes us call glFlush directly when using native layers, rather than going through the misleadingly-named GLContext::SwapBuffers method.
Differential Revision: https://phabricator.services.mozilla.com/D57062
--HG--
extra : moz-landing-system : lando
All usage of `synthesizeDragStart()` is, starting drag, cancel `dragstart`,
and finally compares `dataTransfer` items and given expected data. So,
we can make the users use `synthesizePlainDragAndDrop()` instead. It's
better API because it computes position of mouse operations at runtime and
checks whether the drag start was succeeded with optional logging feature
(i.e., it's easier to debug of intermittent failures).
This patch creates `synthesizePlainDragAndCancel()` for convenience. It
handles `dragstart` instead of the callers.
Differential Revision: https://phabricator.services.mozilla.com/D58214
--HG--
extra : moz-landing-system : lando
The failures which you see running the tests on high DPI display are caused by
`synthesizeQuery*` returns device pixels, but some of the failures
calculating/comparing with CSS pixels, or the other of them caused just
rounding error. This patch makes they refer `window.devicePixelRatio` and/or
use `isfuzzy` to compare.
The patched tests pass on 100%, 125%, 150%, 175%, 200% and 225% on Win10-ja.
Differential Revision: https://phabricator.services.mozilla.com/D58197
--HG--
extra : moz-landing-system : lando