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
This is to prevent Part 1 from breaking
testing/web-platform/tests/css/css-multicol/multicol-span-all-restyle-002.html
After introducing Part 1, we now use CreateContinuingFrame() to create
non-column-span wrapper frames, which use nsFrame::Init() rather than
InitAndRestoreFrame() to initialize them. Because the bits in
aState.mAdditionalStateBits are added to frames only when
nsCSSFrameConstructor::InitAndRestoreFrame() is called. We need a new
way to add the NS_FRAME_PART_OF_IBSPLIT to non-column-span wrapper
frames.
Note that we used to add NS_FRAME_PART_OF_IBSPLIT to both column-span
wrapper and non-column-span wrapper. After this patch, column-span
wrapper won't have NS_FRAME_PART_OF_IBSPLIT. That's fine because
column-span wrappers are not linked with other frames and they
shouldn't get this bit set.
Depends on D15134
Differential Revision: https://phabricator.services.mozilla.com/D15452
--HG--
extra : moz-landing-system : lando
In CreateColumnSpanSiblings(), aInitialBlock can be a DetailsFrame.
Therefore, when creating a non-column-span wrapper, we cannot assume
it's always a block frame. We need to use CreateContinuingFrame to
ensure the correct type of continuation is created.
Differential Revision: https://phabricator.services.mozilla.com/D15134
--HG--
extra : moz-landing-system : lando
To generate this list I searched the changeset history by some authors and keywords related to eslint and clang-format changes, and filtered manually. The search was limited to -900 days ago.
This is the one thing preventing use of a js::Wrapper for a proxy handler that
forwards all ops to a wrapped proxy without entering its compartment. None of
the other ops at this level do compartment asserts.
Callers of this function other than ForwardingProxyHandler do their own asserts
already.
This add a simple function made to be called from gdb, which uses the vixl
decoder to output in a static buffer the string corresponding to a single
instruction.
This is useful when breaking at vixl::Simulator::ExecuteInstruction function, as follow:
(gdb) b vixl::Simulator::ExecuteInstruction
Breakpoint 1 at 0x...: file ../jit/arm64/vixl/MozSimulator-vixl.cpp.
(gdb) command 1
> call vixl::GdbDisassembleInstruction(this->pc_)
> end
Jared Wein
WR Updater Bot
Dzmitry Malyshau
Kartikaya Gupta
Sylvestre Ledru
Vedant Nevetia
Vlad Baicu
Jan-Ivar Bruaroey
Rob Wood
Margareta Eliza Balazs
Masayuki Nakano
Cameron McCormack
Daniel Holbert
Ting-Yu Lin
quasicomputational
arthur.iakab
Gijs Kruitbosch
Felipe Gomes
Boris Zbarsky
James Willcox
Dão Gottwald
Makoto Kato
Cosmin Sabou
Lee Salzman
Nicolas B. Pierron
longsonr
Jason Laster