nsWindow needs configuration change when rendering on Wayland:
- Always draw to mContainer on Wayland as we can't create custom subsurface for
mShell GdkWindow and listen events on mContainer then.
- GTK_WINDOW_TOPLEVEL can't be positioned on Wayland so create popup windows
as GTK_WINDOW_POPUP to control window position on Wayland.
- Create ePopupTypeMenu GdkWindow as GDK_WINDOW_TYPE_HINT_UTILITY instead of
GDK_WINDOW_TYPE_HINT_POPUP_MENU to create it as subsurface (Bug 1423598).
- Don't do pointer grab on Wayland (see Bug 1377084 for reference).
MozReview-Commit-ID: 6InzhTONtrD
--HG--
extra : rebase_source : 356112c2e8f80569ca4b2e41fa0747d71da21d89
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
Wayland compositors do not support GDK_DECOR_BORDER so use CSD decorations exclusively.
MozReview-Commit-ID: 8gzDcw2AumI
--HG--
extra : rebase_source : 4d319155d220420a768de619e7043dd56f6ee667
To have any effect we need to call gdk_window_set_decorations() on top-level GdkWindow only.
When rendering to mContainer the mGdkWindow belongs to mContainer so we need to get the window
from mShell explicitly.
MozReview-Commit-ID: KLKlVJbgg3
--HG--
extra : rebase_source : c17310949e067dca540bf269f12db135e6582ebc
When drawing to mContainer we still need to honor mShell as top-level window.
It means we have to listen property-notify-event there (as it's window specific),
get _NET_FRAME_EXTENTS here and use at nsWindow::SetWindowClass().
MozReview-Commit-ID: HYbNS0Lfyjy
--HG--
extra : rebase_source : f03cb4657a36238fd93b47b94ace48a325648296
This patch adds following Microsoft's IMEs into the black list which set
their open state to "closed" when input scope is set to IS_URL and sets
input scope for the URL bar to IS_DEFAULT.
Additionally, this adds a new pref to disable this hack because a lot of
users will affect this hack but perhaps, somebody may not like this if
they use tablet.
The new black listed IMEs:
- Microsoft Bopomofo
- Microsoft ChangJie
- Microsoft Phonetic
- Microsoft Quick
- Microsoft New ChangJie
- Microsoft New Phonetic
- Microsoft New Quick
- Microsoft Pinyin
- Microsoft Pinyin New Experience Input Style
- Microsoft Wubi
- Microsoft IME for Korean (except on Win7)
- Microsoft Old Hangul
MozReview-Commit-ID: BwJKFcu80B8
--HG--
extra : rebase_source : 75aeed04504b476520102984ab6e7875c98b36c8
Track the Gecko ready state in TextInputController through
GeckoSession's NativeQueue, and only pass through input calls when Gecko
is ready.
MozReview-Commit-ID: KugQ6whg2QA
--HG--
extra : rebase_source : 6ea266d9746d22c58cdd21c7122fa7f20ec730fc
There may be some pending input events in the queue of thread when content starts a dnd operation. Spec says that input events should be suppressed when there is a dnd operation. Add a flag in ESM and turn on/off when start/finish a dnd operation. Checking the flag in PresShell::HandleEvent because we may start a dnd operation with pointermove and we want to suppress the mousemove as well.
MozReview-Commit-ID: 43NZrA7SW4c
We implement PointerEvent.getCoalescedEvents as
1. Clone the widget events we coalesced.
2. Convert them to dom::PointerEvent when user calls getCoalescedEvents.
MozReview-Commit-ID: 8IKw4PbUsDD
We call PDFiumParent::Close twice under certain conditions. Once in
PDFiumProcessParent::Delete, and once in PDFiumProcessParent's dtor. So we may
hit MOZ_ABORT which tell us that we are trying to close a closed channel.
This patch prevents hitting this abort by:
1. Only close the channel in PDFiumProcessParent::Delete, remove another call
in PDFiumProcessParent's dtor. (Please see the change in
PDFiumProcessParent.cpp).
2. Remove PDFiumParent::AbortConversion and relative code. We can just use
PDFiumParent::EndConversion instead. When calling PDFiumParent::Close, we
actually close the IPC channel *synchronously*, which means there is no need
to register a callback by PDFiumParent::AbortConversion to receive
actor-destroy callback.
MozReview-Commit-ID: 9i5j6t54J3h
--HG--
extra : rebase_source : 5f74ebc1ecc29e9983c30ca2dd63e0b49bd24a50
WindowSurfaceWayland is Wayland implementation of WindowSurface class.
One WindowSurfaceWayland object manages drawing of one nsWindow so
those are tied 1:1. It implements base Lock() and Commit() interfaces
from WindowSurface. At Wayland side it represents one wl_surface object.
To perform visualiation of nsWindow, WindowSurfaceWayland contains
one wl_surface and two wl_buffer (by WindowBackBuffer) objects
(as we use double buffering). When nsWindow drawing is finished to
wl_buffer, the wl_buffer is attached to wl_surface and it's sent to
Wayland compositor.
MozReview-Commit-ID: 9NoamtF87e6
--HG--
extra : rebase_source : e942b28f1eaa4b1c24c6c4df6894db8d3d789e7e
wl_buffer is a main Wayland object with graphics data. wl_buffer basically represent one complete window screen.
When double buffering is involved every window (GdkWindow in our case) utilises two wl_buffers which are cycled.
One is filed with data by application and one is rendered by compositor.
WindowBackBuffer class manages one wl_buffer. It owns wl_buffer object, owns WaylandShmPool (which provides shared memory)
and ties them together.
MozReview-Commit-ID: v8Hlezo7oD
--HG--
extra : rebase_source : 40bffbbae2ee0c8f67d442ee2c5a62be43fafb44
We allocate shared memory (shm) by mmap(..., MAP_SHARED,...) as an interface between wayland based application
and wayland compositor. We draw our graphics data to the shm and handle to wayland compositor by wl_buffer/wl_surface.
WaylandShmPool acts as a manager of the allocated memory. Allocates it, holds reference to it and releases it.
MozReview-Commit-ID: CY6oEIl4Vxa
--HG--
extra : rebase_source : c43da8728e11e133cb021b1832382c1a39695a1a
Refactor ncClipboard::GetData() for better readability, add nsClipboard::SetTransferableData()
to send clipboard data to nsITransferable.
According to Gtk people [1] we can't mix free()/g_free() and malloc()/g_malloc() calls.
Existing nsClipboard code mixes that on some places which can lead to issued on glib built
with specific flags (ENABLE_MEM_PROFILE or ENABLE_MEM_CHECK).
[1] https://mail.gnome.org/archives/gtk-list/2000-July/msg00002.html
MozReview-Commit-ID: GvkUGSttVGO
--HG--
extra : rebase_source : 99801e1dc97e24a8d68fe7f3585562bb541c6628
Move GeckoEditableClient and GeckoEditableListener to inside
TextInputController, next to TextInputController.Delegate. This
consolidates the three internal interfaces used for IME in one place.
The patch also changes the last notifyIMEContext parameter to an int
flag to indicate private browsing or user action. This allows for future
expansion without adding more parameters to notifyIMEContext.
MozReview-Commit-ID: BjscdNr9TkO
--HG--
extra : rebase_source : 87166a55e5978eda4a7c3065db9b68658e33af35
Remove InputConnectionListener, which was replaced by
TextInputController.Delegate, and remove IME_STATE_PLUGIN, which is not
used anymore.
MozReview-Commit-ID: GCbJXWNCmTk
--HG--
extra : rebase_source : c90bc79585ce4c5b9c0de5e07b0ea52531b65e04
Use the new TextInputController API in GeckoView to process key events
and input method interactions.
MozReview-Commit-ID: H0oyCDkGHul
--HG--
extra : rebase_source : a0ab70e77aa05b7d3aa05982c47299a0222f3ee5
Add TextInputController and add a getter for it in GeckoSession.
TextInputController is used to process key events and to interact with
the input method manager.
MozReview-Commit-ID: 1j2Moqukf8U
--HG--
extra : rebase_source : 03fee51ba3e2034b8689c4fa6fe58f7432dc1ad4
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt