widget/cocoa/nsChildView.mm:249:6 [-Wmissing-prototypes] no previous prototype for function 'EnsureLogInitialized'
Depends on D20087
Differential Revision: https://phabricator.services.mozilla.com/D20088
--HG--
extra : moz-landing-system : lando
widget/cocoa/nsChildView.mm:1932:21 [-Wmissing-prototypes] no previous prototype for function 'TextureSizeForSize'
widget/cocoa/nsCocoaUtils.mm:351:6 [-Wmissing-prototypes] no previous prototype for function 'data_ss_release_callback'
Differential Revision: https://phabricator.services.mozilla.com/D20087
--HG--
extra : moz-landing-system : lando
In order to get the alpha channel when encoding BMP images from a
surface, we need to supply bmp=32 in the encoder options.
Differential Revision: https://phabricator.services.mozilla.com/D19835
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
The only caller wants CSS pixels, no need to go back and forth.
This is the last dependency on the pres context, I think, from the style system
font code.
Differential Revision: https://phabricator.services.mozilla.com/D19147
This is a clearer implementation that achieves the same thing.
Moreover, disabling the clearing by overriding drawRect wouldn't work in
CoreAnimation windows because in CoreAnimation windows, the clearing happens
through a property of the NSVisualEffectView's CALayer, and not through the
view's drawRect implementation - drawRect probably isn't even called in that
context.
Differential Revision: https://phabricator.services.mozilla.com/D19601
--HG--
extra : moz-landing-system : lando
This has two advantages:
- The drawing will now correctly be placed "on top" of the vibrancy views.
- We can turn this new view into a layer-hosting view. Layer-hosting views are
supposed to be leaf NSViews; they shouldn't have any children.
Differential Revision: https://phabricator.services.mozilla.com/D19600
--HG--
extra : moz-landing-system : lando
Otherwise, any views inside the contentView are imbued with a vibrant effect, and
even non-NSVisualEffectView NSViews subtract from the vibrant region of any actual
vibrant views they overlap. This would cause the PixelHostingView to 'erase' the
blue context menu item highlighting.
This behavior is documented on NSVisualEffectView:
> It is recommended that you enable vibrancy only in the leaf views of your view
> hierarchy. Subviews inherit the vibrancy of their parent. Once enabled in a
> parent view, a subview cannot turn off vibrancy. As a result, enabling
> vibrancy in a parent view can lead to subviews that look incorrect if they are
> not designed to take advantage of the vibrancy effect.
Differential Revision: https://phabricator.services.mozilla.com/D19599
--HG--
extra : moz-landing-system : lando
NSView hierarchy before:
- window contentView
- ChildView
- NonDraggableView 1
- NonDraggableView 2
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
NSView hierarchy after:
- window contentView
- ChildView
- ViewRegionContainerView
- NonDraggableView 1
- NonDraggableView 2
- ViewRegionContainerView
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
This allows us to give those container views a new sibling view which stays
fixed in z-order with respect to the NSViews that get created by
mNonDraggableRegion and mVibrancyManager. More specifically, I'm going to add a
view for the drawing of our ChildView ("PixelHostingView") which is going to be
a direct child of the Gecko "ChildView" and a sibling of the
ViewRegionContainerViews; the PixelHostingView needs to always stay on top of
the vibrancy views.
Without the wrapper around the vibrancy views, whenever the vibrant region
changes, a vibrant view would be placed on top of the PixelHostingView and the
order would be wrong.
Differential Revision: https://phabricator.services.mozilla.com/D19598
--HG--
extra : moz-landing-system : lando
This was added in bug 476393 in order to work around a problem with the Java plug-in.
We no longer support that plug-in.
The comment also mentions NSTexturedBackgroundWindowMask which we stopped using in bug 1335191.
Differential Revision: https://phabricator.services.mozilla.com/D19558
--HG--
extra : moz-landing-system : lando
This method could only return something non-null in embedding situations,
in which our ChildView was a subview of somebody else's NSView that conforms
to the mozView protocol. Such a situation hasn't existed for about 10 years.
Differential Revision: https://phabricator.services.mozilla.com/D19555
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
When GDK_BACKEND is wayland, widget is not fully mapped during creating CompositorSession. Needs to create valid EGLSurface after widget is fully mapped.
Differential Revision: https://phabricator.services.mozilla.com/D18940
Chromium does workaround for scrolling with touch and avoid bitmap allocation when child window is used for DirectComposition. It improves performance of WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D18659
During security.sandbox.gpu.level=1, compositor window's parent cannot be set in GPU process, it needs to be set in UI process.
Differential Revision: https://phabricator.services.mozilla.com/D18811
Recently we quit nsWindow::OnWindowStateEvent()/window_state_event handler when titlebar needs an update due to focus change.
That's incorrect as we need to process other information from the handler - maxminized/normal window state.
Differential Revision: https://phabricator.services.mozilla.com/D18681
--HG--
extra : moz-landing-system : lando
Unfortunately, we're not sure whether ibus always handles non-dead key events
asynchronously or synchoronously. Therefore, for safer fix, this patch makes
IMContextWrapper::OnKeyEvent() decide that with the result of
gtk_im_context_filter_keypress(). If active IME is ibus and it consumes non-
synthesized events on password fields, it adjusts probablyHandledAsynchronously
value.
So, this patch changes the behavior of only when:
- active IME is ibus.
- only when a password field or ime-mode:disabled field has focus.
- not in dead key sequence.
- and the key event is consumed by ibus but nothing happend.
This must be enough safe to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D18635
--HG--
extra : moz-landing-system : lando
Now, we believe that when `maybeHandledAsynchronously` is set to true,
ibus handles the event asynchronously in usual cases. However, the behavior
of ibus on password field is unclear. Currently, on Ubuntu 18.04,
Ubuntu 18.10 and Debian Cinnamon (9.6 / 3.2.7), ibus handles key events
asynchronously even in password fields even though I confirmed it was not
so at initial fix. So, it could be just my mistake, but we need to prepare
for both cases here for safer fix.
So, in the following patch, I need to add another variable for weaker
decision, and we treat `maybeHandledAsynchronously` stronger than its
nuance. Therefore, this patch renames it to `probablyHandledAsynchronously`.
Differential Revision: https://phabricator.services.mozilla.com/D18634
--HG--
extra : moz-landing-system : lando
Casting non-void result to `void*` causes warning of clang. Additionally,
perhaps, we should use `Unused <<` because of modern style.
And also this patch makes widget/windows is treated as "warning as errors"
because this patch fixes the last warning.
Differential Revision: https://phabricator.services.mozilla.com/D17216
--HG--
extra : moz-landing-system : lando
So that we can query the test value in the child process properly.
Note that the APIs used for setting the prefers-reduced-motion value for testing
are only used on Android and MacOSX. As for MacOSX we have a different
machinery (see bug 1486971) to deliver the test value without spinning native
event loop in the child process so the change here is valid only for Android.
Differential Revision: https://phabricator.services.mozilla.com/D18311
--HG--
extra : moz-landing-system : lando
When hardware acceleration is enabled, GLContextGLX::FindVisual() is used to choose visual. When widget does not request AlphaVisual, the FindVisual() always choose RGB(24bit) visual. It causes to loose alpha during readback.
Differential Revision: https://phabricator.services.mozilla.com/D18179
--HG--
extra : moz-landing-system : lando
We currently use ParentLayer pixels in GestureEventListener, it should
be Screen pixels because we care about physical distances and
thresholds, not layer-relative ones.
Differential Revision: https://phabricator.services.mozilla.com/D17042
--HG--
extra : moz-landing-system : lando
This stops the use of some win32k calls during start-up that will fail and in
some cases cause a crash.
It also moves the MITIGATION_DYNAMIC_CODE_DISABLE to be enabled after start-up.
This is required because the hooks to fake the user32 and gdi32 initialization
are applied as the DLLs load and the dynamic code disable blocks that.
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
DisplaySystemMenu() does not handle nsSizeMode_Invalid that causes warning of
clang. This patch makes it treat nsSizeMode_Invalid. When it receives the
value, it will call NS_ASSERTION() to be detectable on debug builds during
automated tests.
Additionally, this adds default case into the switch statement with
MOZ_ASSERT_UNREACHABLE(). Then, when somebody adds new nsSizeMode, they
can detect it with crash in debug build if they forget to change this method.
Differential Revision: https://phabricator.services.mozilla.com/D17217
--HG--
extra : moz-landing-system : lando
The method was added by bug 506926, but not sure when this becomes an orphan.
Differential Revision: https://phabricator.services.mozilla.com/D17215
--HG--
extra : moz-landing-system : lando
Use only ':' separator instead of 'menu:' to place titlebar buttons as the menu may not be always present.
Differential Revision: https://phabricator.services.mozilla.com/D17480
--HG--
extra : moz-landing-system : lando
To support rounded corners of Gtk+ titlebar themes (Adwaita, Radiance..) in GNOME we need to use X shape mask
as fully transparent toplevel window causes various issues (like Bug 1516224).
We draw mShell as transparent and mContainer as non-transparent with shape mask applied. The shape mask
is generated only when titlebar rendering is enabled and it's generated from GtkHeaderBar Widget
to match the exact look.
We use existing mTransparencyBitmap for the shape mask where mTransparencyBitmapForTitlebar controls
whether it's a general shape mask or our specialised shape for titlebar only.
This is already enabled for GNOME environment by default. So there's a new preference
widget.default-hidden-titlebar added to easily disable it if any issue appears
during testing.
Differential Revision: https://phabricator.services.mozilla.com/D17283
--HG--
extra : moz-landing-system : lando
nsDataObj::GetDib() calls GetLastError() API immediately after calling
GlobalAlloc() and just return E_FAIL in such case. So, we don't need to
call it.
Differential Revision: https://phabricator.services.mozilla.com/D17214
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
To avoid FlushIMEChanges per updating IME composition, we calculate composition count in DoReplaceText. But when using GV+e10s, this calculation is sometimes invalid since NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED event isn't received per PendingComposition. Because, IMEStateManager will merge this completed events due to optimization of IME event.
Also, DoUpdateComposition calls SetPendingComposition, but it doesn't touch mIMEActiveCompositionCount,
So when using some IME, this value is minus or forever non-zero on some IMEs.
So we shouldn't use atomic count. When receiving NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED, we should reset it and allow IMEFlushChanges since Gecko has already handled all IME composition events in event queues.
Differential Revision: https://phabricator.services.mozilla.com/D14668
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
This prevents mouse events from firing on browsers in unfocused windows. It used to be done
with the [clickthrough=never] attribute set from XBL content.
Differential Revision: https://phabricator.services.mozilla.com/D16498
--HG--
extra : moz-landing-system : lando
Also add widget.allow-gtk-native-file-chooser preference value to force enable on all systems.
Differential Revision: https://phabricator.services.mozilla.com/D16184
--HG--
extra : moz-landing-system : lando
Because we don't know when the PlaySound API stop/finish playing. So when starting to play a sound, we should call PlaySound(0,0,PURGE) to stop playing then free the last data sound.
Differential Revision: https://phabricator.services.mozilla.com/D14554
--HG--
extra : moz-landing-system : lando
I needed to scale the layout device pixels coming from Windows before passing them to ScreenForRect(). Also, I'm using GetRect() directly instead of GetRectDisplayPix() * scale now, to avoid an unnecessary double scale & round which was making fullscreen windows off by one pixel in many cases.
Differential Revision: https://phabricator.services.mozilla.com/D15604
--HG--
extra : moz-landing-system : lando
gfxUtils::EncodeSourceSurface no longer uses a stringly-typed API to create a
`imgIEncoder` for the relevant MIME type. Instead, we now use an enum class and
switch on it to create the encoder.
Depends on D14816
Differential Revision: https://phabricator.services.mozilla.com/D14817
--HG--
extra : moz-landing-system : lando
Port to separate SpatialId from ClipId in Webrender API (WR PR #3251).
Patch was originally written and reviewed on bug 1503447.
Depends on D16005
Differential Revision: https://phabricator.services.mozilla.com/D16006
--HG--
extra : moz-landing-system : lando
We haven't logged KeymapWrapper::HandleKeyPressEvent() nor
KeymapWrapper::HandleKeyReleaseEvent(). Therefore, this patch makes them
put their behavior into the log.
Additionally, KeymapWrapper::InitKeyEvent() does not log enough the result
of initialized WidgetkeyboardEvent. This patch makes it log more.
With those changes, we can get the log of:
- detail of dispatched keyboard events
- which key event didn't cause keyboard events
- which keyboard event was consumed
Note that the utility methods are copied from widget/windows. Perhaps,
we should create XP logging helper for keyboard/IME later.
Differential Revision: https://phabricator.services.mozilla.com/D15324
--HG--
extra : moz-landing-system : lando
Move all implementation of nsWindow::OnKeyPress() and nsWindow::OnKeyRelease()
into KeymapWrapper because the implementation is a little bit complicated
but not loggable. When we get bug reports which depend on environment around
IME/key handling like bug 1498823, it's useful to log those methods behavior
too.
Differential Revision: https://phabricator.services.mozilla.com/D15323
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Some unusual keyboard layout may map a function key only with some
modifiers. For example, Hatchak keyboard layout maps Tab key to
"Digit3" key and Backspace key to Level3 Shift+"Digit3" key. So,
when Level3 Shift is active, the modifier state of the "Digit3" key
event shouldn't be ignored because computed keyCode value becomes
DOM_VK_TAB (9) rather than DOM_VK_BACK_SPACE (8).
This patch makes KeymapWrapper::ComputeDOMKeyCode() compute keyCode
value of non-printable key event with its modifier state first. If
it cannot map to a DOM keyCode value, then, it keeps ignoring the
modifier state for backward compatibility and making web apps be able
to identify the key as far as possible.
This patch implements InputType.inputType which is declared by Input Events.
The attribute has already been implemented by Chrome and Safari. Chrome
implements Input Events Level 1, but Safari implements Input Events Level 2.
Difference between them is only whether it supports "insertFromComposition",
"deleteByComposition" and "deleteCompositionText". This patch makes the
level switchable with pref and takes Level 1 by default because Level 2 is
still unstable around event order with composition events.
For reducing string copy cost at dispatching "input" event, this patch
makes EditorInternalInputEvent store valid input-type as enum class,
EditorInputType and resolves it to string value when
dom::InputEvent::GetInputType() is called. Note that the reason why
this patch names the enum class as EditorInputType is, there is InputType
enum class already for avoiding conflict the name, this appends "Editor"
prefix because "input" and "beforeinput" events are fired only when an
editor has focus.
Differential Revision: https://phabricator.services.mozilla.com/D14128
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
With an event filter method, we're logging all key events on any widgets to
check whether a key is pressed or not, to set
WidgetKeyboardEvent::mIsRepeat properly. If iBus and Fcitx work as expected,
they synthesize key events with setting their own modifier state which indicate
the events are synthesized by IME. In this expected case, synthesized key
events are not caught by the filter.
On the other hand, in some environment, they keep handling key events
asynchronously but they or something another module synthesizes key events
without the flag and such events are caught by the filter because the events
are posted into the event queue. Therefore, we decide that such synthesized
events are always generated by auto-repeat (first events which are always
filtered by IME are treated as first press, and then, synthesized events are
treated as repeated events because of no key release events).
This patch makes KeymapWrapper::FilterEvents() ignore coming KeyPress
events if:
- the time is exactly same as previous KeyPress event
- and IMContextWrapper instance is now waiting a GDK_KEY_PRESS event
- and hardware_keycode of waiting GDK_KEY_PRESS event is same as
keyCode of the KeyPress event
Differential Revision: https://phabricator.services.mozilla.com/D15380
--HG--
extra : moz-landing-system : lando
All of the current usage can survive a timeout, and we'd rather
that than a deadlock. Future code that does want to risk a
deadlock can call `GeckoThread.waitOnGeckoForever` instead.
Differential Revision: https://phabricator.services.mozilla.com/D14560
--HG--
extra : moz-landing-system : lando
According to the log of bug 1498823, ibus won't set IBUS_IGNORED_MASK to
modifier flags when it synthesizes the event for asynchronous handling in
some environments.
Currently, we assume that iBus and Fcitx set IBUS_IGNORED_MASK or
FcitxKeyState_IgnoredMask. So, we put both real key events and synthesized
key events into the posting event queue and that causes using a lot of
memory until the editor is blurred. Fortunately, timestamp of synthesized
key events are always same as their original events. Therefore, we can look
for original event from the positing event queue.
Although we have gotten no bug reports about this issue of Fcitx, but this
patch adds same hack for Fcitx too because the runtime cost is not
expensive but the symptom is really serious.
Differential Revision: https://phabricator.services.mozilla.com/D15321
--HG--
extra : moz-landing-system : lando
The VisualViewport events are all nice and shiny, but unfortunately not quite
what is needed for the session store.
Firstly, the spec wants the "scroll" event to be fired only when the *relative*
offset between visual and layout viewport changes. The session store however
records the absolute offset and as such is interested in when *that* changes.
Secondly, again as per the spec the events don't bubble, and with the default
DOMEventTargetHelper implementation they don't escape the VisualViewport during
capturing, either. This means that any event listener must be added directly on
the VisualViewport itself in order to capture any events.
This might have been intended because the events use the same names as the
normal "scroll"/"resize" events, and as such you cannot specify separate event
listeners for VisualViewport and non-VisualViewport "scroll" events if both
events end up being dispatched to the same element (you can only try to filter
after the fact by looking at the originalTarget of the event).
At the same time, the VisualViewport is attached to the inner Window, and so
each time you navigate, you also get a different VisualViewport object.
All of this might be totally fine from the perspective of a page script, because
in that case you won't care anyway about what happens when the current page goes
away.
From the session store perspective on the other hand (especially Fennec's non-
e10s session store design), this is rather unfortunate because we don't want to
have to keep registering event listeners
a) manually for each subframe
b) each time the page navigates
The event target chain problem could be solved by letting the scroll events
escape the VisualViewport during the capturing phase (which the spec doesn't say
anything about), but this would mean that any scroll listener attached to a
window/browser/... that uses capturing will now catch both layout and visual
viewport scroll events.
In some cases this might even be beneficial, but in others (e.g. bug 1498812
comment 21) I'd like to specifically decide which kind of scroll event to
capture. Having to look at event.originalTarget to distinguish the two kinds
might be defensible in test code, but in case this distinction would be needed
in production code as well, given the existence of a C++-based filtering helper
in nsSessionStoreUtils for another use case where (scroll) events need to be
filtered, JS-based scroll event filtering might be a bad idea.
Additionally, in any case this wouldn't solve the fundamental conflict between
the spec and the session store about *when* the "scroll" event should be fired
in the first place.
Hence I'd like to introduce a separate set of events with distinct event names,
which will be dispatched according to the requirements of our internal users
(i.e. currently the session store). To avoid potential web compatibility issues
down the road, for now these events will be dispatched only to event listeners
registered in the system group (allowing *all* Chrome event listeners cannot be
done because checking the Chrome status of each event target might be too
expensive for frequently dispatched events).
Differential Revision: https://phabricator.services.mozilla.com/D14046
--HG--
extra : moz-landing-system : lando
The semantics of the VisualViewport resize/scroll events aren't quite what is
needed for internal browser usage, so we need a separate set of events that can
be used e.g. by the session store. To avoid future web compatibility issues,
that event should be kept internal, however none of the existing
options to achieve that are suitable:
- mNoContentDispatch can actually end up being dispatched to content after all
and as per its comment preferably shouldn't be used any more for new features
- mOnlySystemGroupDispatchInContent would work perfectly, except that it
shouldn't be used for frequent events, which the resize/scroll events
arguably are
- mOnlyChromeDispatch doesn't work for the Desktop session store's content
script, plus it might have the same performance problems as
mOnlySystemGroupDispatchInContent
Therefore, I propose to introduce a new mOnlySystemGroupDispatch event flag,
which skips the comparatively expensive IsCurrentTargetChrome() check and relies
only on the event listener having been registered in the system group.
Differential Revision: https://phabricator.services.mozilla.com/D14045
--HG--
extra : moz-landing-system : lando
To avoid FlushIMEChanges per updating IME composition, we calculate composition count in DoReplaceText. But when using GV+e10s, this calculation is sometimes invalid since NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED event isn't received per PendingComposition. Because, IMEStateManager will merge this completed events due to optimization of IME event.
Also, DoUpdateComposition calls SetPendingComposition, but it doesn't touch mIMEActiveCompositionCount,
So when using some IME, this value is minus or forever non-zero on some IMEs.
So we shouldn't use atomic count. When receiving NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED, we should reset it and allow IMEFlushChanges since Gecko has already handled all IME composition events in event queues.
Differential Revision: https://phabricator.services.mozilla.com/D14668
--HG--
extra : moz-landing-system : lando
Native toast notification uses WinUtils::WriteBitmap to bitmap for notification now. Since it uses old BITMAPINFOHEADER structure, it doesn't support alpha.
So I would like to support alpha value to WinUtils::WriteBitmap.
Differential Revision: https://phabricator.services.mozilla.com/D14670
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
IMMHandler and TSFTextStore are good class to put native caret when they have
enough information. However, for example, IMMHandler may not have its singleton
instance until first composition of IMM-IME starts. Therefore, typically,
IMEHandler is a good class to put native caret without composition.
This patch adds IMEHandler::MaybeCreateNativeCaret(), and if it won't create
native caret because not yet received WM_GETOBJCT for OBJID_CARET, we should
fire window event for MSAA applications. If there is new MSAA application
retrieves OBJID_CARET, we'll receive WM_GETOBJECT for OBJID_CARET
asynchronously. Then, we should start to put native caret for such
applications.
Note that if we create native caret, some versions of ATOK refers the native
caret and the behavior becomes worse than usual. Therefore, we need to
keep not using native caret as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D13962
--HG--
extra : moz-landing-system : lando
If WM_GETOBJECT for OBJID_CARET is received but a11y module is not active,
IME module should create native caret over our caret because Windows will
handle the request with native caret automatically and we don't need to
enable a11y module only for it.
This patch makes IMEHandler store whether such message has been received and
makes TSFTextStore create native caret when composition, selection or layout
is changed because especially when there is composition, only TSFTextStore
knows correct position to put caret if there is composition or some dispatched
events have not been handled by content process yet.
Note that IMMHandler already does that since some legacy IMEs require native
caret to show its UI and we cannot check active IME strictly. Therefore, this
patch does not touch IMMHandler.
Differential Revision: https://phabricator.services.mozilla.com/D13961
--HG--
extra : moz-landing-system : lando
IMEHandler needs to create native caret later (when there is no composition).
Therefore, IMEHandler should manage whether it creates native caret or not
and IMMHandler and TSFTextStore should create/destroy native caret via
IMEHandler.
Note that this patch makes IMMHandler stops managing whether native caret
is created for plugin or not because native caret is created only one instance
and anyway IME handlers should stop managing native caret when they loses
focus.
Differential Revision: https://phabricator.services.mozilla.com/D13960
--HG--
extra : moz-landing-system : lando
If a11y module is active, it observers caret position and size, and when caret
position or size is changed, it creates/moves native caret to overlap with
our caret.
On the other hand, IME module also creates native caret if active IME requires
it. Therefore, both of them conflicts each other.
This patch makes IME module stop touching native caret if a11y module is active.
Although, a11y module with Flush Player does not work well for IME. Therefore,
this patch keeps the conflict between them as-is for now.
Differential Revision: https://phabricator.services.mozilla.com/D13959
--HG--
extra : moz-landing-system : lando
If TSFTextStore fails to get selection, e.g., the content is really odd like
fuzzing tests, its mSelectionForTSF is marked as dirty. However, Windows may
try to retrieve writing mode while we're creating new TSFTextStore. Then, we
may hit MOZ_ASSERT(!mDirty) in TSFTextStore::Selection::GetWritingMode() in
debug build.
So, we need to make some callers of GetWritingMode() check whether selection
is marked as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D14137
--HG--
extra : moz-landing-system : lando
MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
This issue is e10s only.
Even if calling SetSelection, it doesn't reset selection cache in
TextInputHandler. Since selection cache is updated by OnSelectionChange
asynchronous, we should set temporary range when having replacement range.
Also, even if marking dirty doesn't fix this issue. Content cache may return
other range such as caret position instead of replacement range by SetSelection.
Differential Revision: https://phabricator.services.mozilla.com/D14002
--HG--
extra : moz-landing-system : lando
It's not quaranteed that we have a valid wl_surface at GtkWidget::map event.
In that case create it at GtkWidget::map-event handler which is called after
widget show.
Differential Revision: https://phabricator.services.mozilla.com/D13979
--HG--
extra : moz-landing-system : lando
- Wayland - Set proper scale to wl_egl_window when it's created and resized
- Wayland - Remove unused gtk_widget_set_app_paintable()
Differential Revision: https://phabricator.services.mozilla.com/D13725
--HG--
extra : moz-landing-system : lando
Use frame callback to determine if we can draw to wl_surface owned by GtkWidget and use it as a base for EGL Window.
Differential Revision: https://phabricator.services.mozilla.com/D13722
--HG--
extra : moz-landing-system : lando
We can't listen on GdkDeviceManager as we need to track device changes here. Rvert back
the old working setup based on wl_seat listeners. Also check if the keyboard is already present
(before it's created here) to avoid memory leaks.
Differential Revision: https://phabricator.services.mozilla.com/D13727
--HG--
extra : moz-landing-system : lando
