This is what Safari does, i.e. once after a swipe gesture has started to a
direction where there is no navigation history, then even if the swipe gesture
switched to the opposite direction where navigation can happen, swipe navigation
will never happen. Chrome looks like they are trying to do swipe navigation in
such cases, but it looks like they sometimes fail it, the swipe navigation
indicator (an arrow image) doesn't show up sometime when the swipe navigation
goes to the opposite direction.
This change fixes stuck-in-overscroll situations where user swipes horizontally
to a direction where navigation is impossible during overscrolling, but doesn't
fix situations where navigation is possible but the user cancels the navigation.
To fix the later situations we need a different fix apart from this change.
The mochitest in this change doesn't test the stuck-in-overscroll situations at
all because we need to write a browser mochitest since swipe gesture is
implemented as a browser feature but unfortunately SpecialPowers.snapshotWindow
doesn't capture overscrolled gutter regions for some reasons, so instead the
test checks whether the swipe gesture module keeps capturing wheel events in the
situations where navigation is impossible.
Differential Revision: https://phabricator.services.mozilla.com/D113636
Removes NPAPI plugin features from tests outside of dom/plugins. Some tests are updated to avoid NPAPI behavior and others are deleted if they no longer offer anthing useful.
Differential Revision: https://phabricator.services.mozilla.com/D107134
Removes NPAPI plugin features from tests outside of dom/plugins. Some tests are updated to avoid NPAPI behavior and others are deleted if they no longer offer anthing useful.
Differential Revision: https://phabricator.services.mozilla.com/D107134
In the case of nsStandaloneNativeMenu, the root nsMenuX has the nsStandaloneNativeMenu as its parent.
But the parent's NativeNSMenu() is the root nsMenuX's NativeNSMenu().
So when we were removing the collapsed="true" attribute from the root nsMenuX of an nsStandaloneNativeMenu,
`parentMenu` and `mNativeMenu` were the same object. So we would insert mNativeMenuItem into mNativeMenu (as a subitem),
and then also set mNativeMenuItem.submenu = mNativeMenu, creating a cyclic menu structure.
I've added a test for this scenario.
It turns out though that without this patch, the test doesn't actually fail, because the collapsed attribute
handling also calls SetRebuild(true). So while the test would briefly create the cyclic structure, this
bug would be corrected by the MenuOpened calls which would rebuild the menu contents, and then all the
checks from the test would still succeed.
Depends on D109113
Differential Revision: https://phabricator.services.mozilla.com/D109114
The test assumes that mousemove events are fired with waiting a tick
after synthesizing native mousemove event. However, it's wrong since
synthesizing native mousemove event may run after a tick for waiting
safe time to synthesize a native event.
Differential Revision: https://phabricator.services.mozilla.com/D106136
For minimizing the previous patch changes, `scale`'s default value for
`screenX/Y` is treated as 1.0. It means that `screenX/Y` are device
pixels by default, but `offsetX/Y` are in CSS pixels by default. This
difference may make developers confused. Therefore, we should align the
default unit of them to `screenPixelsPerCSSPixel`. I.e., their default
unit becomes CSS pixels.
Differential Revision: https://phabricator.services.mozilla.com/D105929
For making the test framework/API change easier, such raw API shouldn't be
used directly. Therefore, this patch makes tests using it directly stop
using it and use `synthesizeNativeMouseEvent` instead.
However, this patch does not fix `browser_touch_event_iframes.js` because
it accesses the API from `ContentTask`. So, `EventUtils.js` isn't available
without larger change.
Note that this patch disables `test_bug596600.xhtml` because as I commented
in it, it's completely broken. It depends on the race of next native event
loop and `waitForTick`, and this patch changes the result of the race.
Differential Revision: https://phabricator.services.mozilla.com/D105765
Currently, it takes a raw native message value, but it makes JS content too
complicated. And on Linux, it cannot synthesize non-primary button events
because GDK has only button press and release messages which dont' include
mouse button information.
For solving these problems, this patch creates a new abstract native message
as `nsIWidget::NativeMouseMessage` and makes each widget converts it to
a platform native message.
Additionally, this patch adds an argument to make it possible its callers
to specify pressing or releasing mouse button with a DOM mouse button value.
Note that the following patch adds new argument to
`synthesizeNativeEventMouse*` for mochitests and which will be tested by
new tests.
Differential Revision: https://phabricator.services.mozilla.com/D105763
Surprisingly, they don't take modifiers, and
`nsIWidget::SynthesizeNativeMouseEvent()` which are implementations of
`nsIDOMWindowUtils::SendNativeMouseEvent()` treat given modifier flags
are native's ones, and handle modifiers only on macOS. Therefore, this
patch makes them handle native modifiers of Gecko.
Unfortunately, I'm not so familiar with Android API, and in the short
term, I don't need the support on Android. Therefore, this patch just
adds a TODO comment on Android widget.
Additionally, we don't have a simple way to set modifier only while
posting a mouse input on Windows too. It requires complicated code.
Therefore, I don't add the support for it on Windows too.
Differential Revision: https://phabricator.services.mozilla.com/D105758
Currently, they are never focusable when its type is "plugin".
So, making stop them returning `IMEEnabled::Plugin` won't change
anything, but it guarantees that nobody will see `IMEEnabled::Plugin`
at runtime. This is a preparation for the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D100101
This is another regression by bug 1658948 and Windows only.
When user script calls element.focus() during keyboard event, our TSF client
implementation commits composition string.
It is unnecessary to call SetInputContext when real keybaord event is fired.
Because,
- If keybaord event is fired, virtual keybaord is already shown
- We don't open virtual keyboard when physical keyboard is available on Android
So I shouldn't call SetInputContext on user interaction by keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D98882
UPDATED
-------
widget/tests/test_imestate.html
Test that plugin IME state properly tracks focus
Update to reflect that plugins are not IME focusable.
REMOVED
-------
widget/tests/test_plugin_scroll_consistency.html
On most platforms does nothing but on Windows performs basic test that layout positions and sizes are internally consistent.
widget/tests/test_chrome_context_menus_win.xhtml
Make sure that right-clickable chrome context menus appear when a plugin has focus.
widget/tests/test_plugin_input_event.html
Test plugin keyboard input
Differential Revision: https://phabricator.services.mozilla.com/D95920
This is simple mistake at writing the test.
And also, once fixing the mistake, another bug appears. That is, the second
composition string is not "b", but the following code assumes so. Therefore,
this fixes it too.
Depends on D97269
Differential Revision: https://phabricator.services.mozilla.com/D97270
Currently, it validates the result of `mStart + aInsertPointOffset` with
the following code.
```
CheckedInt<uint32_t> absOffset =
CheckedInt<uint32_t>(mOffset) + aInsertionPointOffset;
```
However, this does not work when `mOffset` is a negative value since it's
converted to unsigned value before adding `aInsertionPointOffset`.
Therefore, when TSF queries first character rect of the document with
`TSFTextStore::GetTextExt()` whose `acpStart` is set to 0, and composition
start is second or later character, the check may fail and anyway, even
if it does not overflow, the computed offset becomes too big and fails
to query character rect anyway.
Therefore, this patch makes its constructor take computed value instead.
Unfortunately, this cannot be tested without writing a big framework to
test async composition event handling because synthesizing similar
query text rect in same process works fine.
Differential Revision: https://phabricator.services.mozilla.com/D97269
UPDATED
-------
widget/tests/test_imestate.html
Test that plugin IME state properly tracks focus
Update to reflect that plugins are not IME focusable.
REMOVED
-------
widget/tests/test_plugin_scroll_consistency.html
On most platforms does nothing but on Windows performs basic test that layout positions and sizes are internally consistent.
widget/tests/test_chrome_context_menus_win.xhtml
Make sure that right-clickable chrome context menus appear when a plugin has focus.
widget/tests/test_plugin_input_event.html
Test plugin keyboard input
Differential Revision: https://phabricator.services.mozilla.com/D95920
This is regression by bug 1658948.
We shouldn't update IME state during composition even if element.focus() is
called to current focused element.
Also, although this depends on netive impelentation of IME handling, I would
like to add unit test for this situation since we might add mock tests for
native IME handling.
Differential Revision: https://phabricator.services.mozilla.com/D96308
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Andrew Halberstadt
Kagami Sascha Rosylight
Csoregi Natalia
Emilio Cobos Alvarez
Hiroyuki Ikezoe
Edgar Chen
David Parks
Markus Stange
Masayuki Nakano
Stephen A Pohl
Tom Schuster
Cameron McCormack
Makoto Kato
Christian Holler
Bogdan Tara
Tarek Ziadé
Andreea Pavel
Kris Maglione
Sonia Singla
Ricky Stewart