For Bug 1733955, we need a support of dynamic enabling/disabling window occlusion by pref. It is for enabling/disabling window occlusion for some mochitests by pref.
Differential Revision: https://phabricator.services.mozilla.com/D129369
gtest is ported from chromium's gtest.
TestWinWindowOcclusionTracker.cpp is from chromium's native_window_occlusion_tracker_unittest.cc.
TestWinWindowOcclusionTrackerInteractive.cpp is from chromium's native_window_occlusion_tracker_win_interactive_test.cc
Differential Revision: https://phabricator.services.mozilla.com/D126757
There are a lot of check of `Document`'s editable state **with** comments. This
means that it's unclear for developers that only `Document` node is editable in
design mode.
Additionally, there are some points which use composed document rather than
uncomposed document even though the raw API uses uncomposed document. Comparing
with the other browsers, checking uncomposed document is compatible behavior,
i.e., nodes in shadow trees are not editable unless `contenteditable`.
Therefore, `nsINode` should have a method to check whether it's in design mode
or not.
Note that it may be called with a node in UA widget. Therefore, this patch
adds new checks if it's in UA widget subtree or native anonymous subtree,
checking whether it's in design mode with its host.
Differential Revision: https://phabricator.services.mozilla.com/D126764
This patch does three things:
* Unifies mac and gtk's buttonactivetext system colors (unships mac's from
content, but it was never meant to be exposed).
* Simplifies the forms.css rules, since <input type=color>'s color property
value doesn't affect its rendering in any meaningful way.
* Adds a buttonactiveface color, which we'll use to provide dark backgrounds
for buttons in Windows dark mode (and is good practice, since generally
every text system color should have a corresponding background).
So as-is it shouldn't change content-exposed behavior (except we stop exposing
the -moz-mac-buttonactivetext to content), but it's a worthy cleanup.
Depends on D127246
Differential Revision: https://phabricator.services.mozilla.com/D127259
Actually, date, datetime-local and time won't set correct `mHTMLInputType`
in `InputContext` since focused `aContent` isn't input element on UAWidget.
Another attribute (`inputmode`) is still correct value since `IMEState` isn't
editable, even if this isn't fixed.
Differential Revision: https://phabricator.services.mozilla.com/D126576
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
sotaro
Emilio Cobos Álvarez
Marian-Vasile Laza
Masayuki Nakano
Makoto Kato
Andi-Bogdan Postelnicu
Haik Aftandilian
Andrew Osmond
Edgar Chen
Neil Deakin
Kagami Sascha Rosylight
Ryan VanderMeulen
Andrew Halberstadt
Csoregi Natalia
Hiroyuki Ikezoe
David Parks
Markus Stange