WebIDL's prefs enables on new window and doesn't apply current window/tab.
So I should move prefs settings to mochitest.ini instead.
When setting pref in mochitest.ini, it applies on all tests. But enterkeyhint
is used on this test only, so others won't be affected.
Differential Revision: https://phabricator.services.mozilla.com/D124183
Blink and WebKit support dynamically change of `inputmode`. When the focused
element's `inputmode` value is changed, software keyboard layout will be
changed by new value.
Actually, Gecko references it when getting focus only now. So we should apply
dynamically change like other browsers.
Also, `enterkeyhint` has same issue. Current WebKit is same behaviour as
Gecko, but Blink is same as `inputmode` behaviour. So I would like to change
this like `inputmode`.
And since WebKit and Blink doesn't commit composition when changing this value,
So we also add "Don't commit composition" flags for it. It depends on IME.
Differential Revision: https://phabricator.services.mozilla.com/D122490
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
Perform additional encoding of URLs before converting to an NSURL as required per the `NSURL URLWithString:` method documentation.
Differential Revision: https://phabricator.services.mozilla.com/D122653
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
It tries to replace a following NBSP with an ASCII white-space if there is.
However, it calls the scan method with start of the replacing range. Therefore,
the assertion in `GetInclusiveNextNBSPPointIfNeedToReplaceWithASCIIWhiteSpace()`
detects this bug.
Note that this occurs only when updating composition string because it's
called with non-collapsed range only for doing it. Otherwise, selected range
has already been deleted by `HTMLEditor::DeleteSelectionAsSubAction()`.
Unfortunately, I don't have how to make this bug appear. It seems that the
path does nothing in the wild because it tries to replace a first character
of composition string from an NBSP to a normal white-space, but it'll be
replaced with new composition string anyway. Therefore, this patch does not
have new tests.
Differential Revision: https://phabricator.services.mozilla.com/D122182
Web apps can modify normal selection even during IME composition and no
browsers stop composition by it. However, our editor tries to delete
non-collapsed selected range before updating composition. Therefore,
we need additional state at handling inserting text whether selection
should be deleted or ignored.
Depends on D121371
Differential Revision: https://phabricator.services.mozilla.com/D121372
It's default value is `true`. `dom.keyboardevent.dispatch_during_composition`
will never be reverted by default in release builds. So, we can drop it from
the tests unless testing the non-default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D119850
Its default value is `true` and it will never be reverted in release builds
by default. Therefore, we can get rid of it from the tests unless testing
non-default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D119849
`beforeinput` event was shipped and it won't be disabled for avoiding confusion
of web developers. So, we can drop the pref setting of
"dom.input_events.beforeinput.enabled" in our tests.
Depends on D119716
Differential Revision: https://phabricator.services.mozilla.com/D119729
It's used only by password field, i.e., only by `TextEditor`, and used
temporarily. Additionally, there is some space in `TextEditor`. So, we
can get rid of it, and make `TextEditor` store it directly.
Note that this allows to skip expensive `nsIEditor::SetFlags()` calls by
`AutoRestoreEditorState`. This may improve setting `<input>.value` performance.
Differential Revision: https://phabricator.services.mozilla.com/D118266
With the previous patch, we know `nsIEditor::eEditorWidgetMask` always
matches with `EditorBase::IsTextEditor()`. And it's not referred from JS
(including comm-central and BlueGriffon). So, we can get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D118262
Some `nsIEditor::eEditor*Mask` flags are now only for `TextEditor` or
`HTMLEditor`. For making it clearer, add `MOZ_ASSERT` to the `SetFlags` and
each flag accessor.
Differential Revision: https://phabricator.services.mozilla.com/D118261
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
Makoto Kato
Andi-Bogdan Postelnicu
Haik Aftandilian
Andrew Osmond
Masayuki Nakano
Edgar Chen
Neil Deakin
Kagami Sascha Rosylight
Ryan VanderMeulen
Andrew Halberstadt
Csoregi Natalia
Emilio Cobos Alvarez
Hiroyuki Ikezoe
David Parks
Markus Stange
Stephen A Pohl
Tom Schuster
Cameron McCormack
Christian Holler