Given the time constraints, and how fiddly this menupopup is (it's a menupopup
masquerading as a panel), I opted to not try to fix bug 985024. Instead, I've
applied the Proton styles as best I can given what I know about the styles
applied for the other menus.
Differential Revision: https://phabricator.services.mozilla.com/D109151
Those command handlers just check whether the given editor is an `HTMLEditor`
or not. Therefore, we should make them check whether the given editor is
a single line editor or not instead.
Differential Revision: https://phabricator.services.mozilla.com/D108572
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
Currently, `Document` checks it only with whether the document is editable
or not. Only with this check, `execCommand` and the other related methods
work only when there is `contenteditable`.
Therefore, this patch makes it to check whether the target is editable or not
with target editor.
Differential Revision: https://phabricator.services.mozilla.com/D108570
For making `execCommand` and related methods with `<input>` and `<textarea>`
even if they are in `contenteditable` and focused, command should be handled
in active editor (focused editor if in foreground window and tab).
However, some commands should be handled by `HTMLEditor` even if an `TextEditor`
has focus. Therefore, this patch adds new enum class which have 3 state into
`InternalCommandData` and makes `AutoEditorCommandTarget` consider it with the
enum class.
Note that the new failures about `contentReadOnly` command will be fixed by
a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D108569
This will guarantee that when `<input>` or `<textarea>` is in `contenteditable`,
`execCommand` and the other related methods work with same command class
instance and same command context (in this case, it's editor instance).
Differential Revision: https://phabricator.services.mozilla.com/D108568
Editor command should be handled in same command table between `ExecCommand`
and the other related methods. However, currently, only `ExecCommand` does
optimized things. For using same logic in the other methods, the code should
be in an independent stack class.
Differential Revision: https://phabricator.services.mozilla.com/D108567
This is a real issue, but realistically we're probably not going to dig
a lot into it, and it wasn't really caused by the regressing bug in any
meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D109532
The automated tests become orange only in macOS and 32bit Windows builds. It
fails when left mouse button down is synthesized in the autoscroller (a XUL
`<panel>` element). Although I'm not sure why that depends on the platform,
APZ cancels active autoscrolling before dispatching `mousedown` event.
Therefore, `AutoScrollParent` nor `AutoScrollChild` cannot block the following
click event.
Therefore, this patch adds new field into `APZEventResult` and set it to `true`
when APZ runs `autoscroll` but canceled by a mouse input. Then, `nsBaseWidget`
can prevent following click event of `eMouseDown` and `eMouseUp` events as
expected before dispatching them into the DOM tree. (FYI: Preventing click
event of either `eMouseDown` or `eMouseUp` can prevent the following `click`
event, etc.)
Differential Revision: https://phabricator.services.mozilla.com/D107325
I was confused by the old flag `this._ignoreMouseEvents`. It's now set to
`true` by `startAutoscroll`, but `stopScroll` does not set it to `false`.
Instead, `this._scrollable` is available for this purpose.
Then, the test does not pass only on 32bit Windows and macOS. The failure is,
when clicking on left mouse button, `click` event is fired in the content.
The difference from the other platforms, the click is handled by APZ on them.
Therefore, there is no chance to consume click event in `AutoScrollParent`,
`AutoScrollChild` nor `browser-custom-element`.
Differential Revision: https://phabricator.services.mozilla.com/D107324
Chrome behaves like this:
1. When user starts autoscroll with a middle click, `mousedown` and `mouseup`
are fired, but `auxclick` nor `paste` event is not fired.
2. When user ends autoscroll with a left click, only `mouseup` event is fired.
I.e, `mousedown` nor `click` event is not fired.
3. When user ends autoscroll with a middle click, only `mouseup` event is fired.
I.e., `mousedown`, `auxclick` nor `paste` events is not fired.
4. When user ends autoscroll with a right click, `mouseup` and `contextmenu`
events are fired, but `mousedown` and `auxclick` events are not fired.
This patch emulates these Chrome's behavior as far as possible. However,
unfortunately, we cannot do exactly same behavior without some big patches
because each widget (`nsWindow` or `nsChildView`) discards a mouse event
which rolled up a widget before dispatching it into the DOM. Therefore,
for now, this patch does not fix the following issues:
1. `mousedown` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the secondary button or on any
buttons on Linux.
2. `mouseup` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the primary button macOS.
3. `click` event and `auxclick` events are fired when clicking outside the
autoscroller with the secondary button.
So, the middle button `click`/`auxclick` events and `paste` event which is
reported to the bug won't be fired with this patch. I'll file follow up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D104652
Chrome and Safari move selection at middle button down and does not modify the
range at middle button up. However, they handle middle button down with
`Shift` key is "continue selection". So, we should handle selection in
nsIFrame when `mousedown` event for middle mouse button is fired, but ignore
multiple selection, drag and drop and maintaining selection for aligning the
behavior to the other browsers.
This patch splits `nsIFrame::HandlePress()` and calls new method which
moves selection from `nsIFrame::HandleEvent()` when middle button is pressed.
(Note that this patch does not check whether middle click paste is enabled
because Chrome moves selection even on Windows which Chrome always disable
middle click paste on.)
With this change, "paste" event target is changed. Previously, we used target
of the preceding `mouseup` event, but we start to use the target of the
preceding `mousedown` event.
Note that even with this patch, we still behave differently from Chrome even
in the following cases:
- middle mouse button down in selected range, we collapse it, but Chrome keeps
the selection.
- middle mouse button click in selected range, we dispatch "paste" event, but
Chrome collapse selection and not dispatch "paste" event.
- middle mouse button down in selected range and up in different element,
Chrome does not modify the range nor dispatch "paste" event.
- Shift + middle mouse button in editable `<table>` works as non-editable
in Chrome, but our editor handles it with special path. Therefore, we
don't modify the range but dispatch "paste" event in the selected range.
Changing them requires bigger change and probably requires some other features'
behavior changes. Therefore, we shouldn't touch these issues until they are
actually reported as web-compat issues.
Differential Revision: https://phabricator.services.mozilla.com/D103997
The test previously depended on the position of the blocked request
in the request list view, This causes the test to fail intermittently
when the list is out of order.
This fix instead finds the request using the name in the url which is
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D109497
When we are guarding that no argument is forwarded, ArgumentsReplacer::visitGuardArgumentsObjectFlags asserts that no formal argument is aliased. This is too general: in strict mode, arguments can be aliased by the call object, but not forwarded.
This patch fixes the check in `anyFormalIsAliased` and renames it for clarity.
(I tried adding assertions in `MaybeForwardToCallObject` that we only mark arguments as forwarded if `script->anyFormalIsAliased()`, but that runs into problems with `arguments.callee.arguments` and `ArgumentsObject::createUnexpected`.)
Differential Revision: https://phabricator.services.mozilla.com/D109413
* We make some changes to heuristicsRegexp.js to improve accuracy. (Nothing else uses these regexps, so they're safe to change.) The commenting out of some languages in the expiration fields are because they caused a lot of false positives, according to Daniel Hertenstein's recollection. In any case, we've never preffed CC autofill on for those languages.
* Delete a few tests from test_known_strings.js and one from test_getInfo.js, which were testing for the presence of regexes we removed.
* Delete tests of CC autofill against third-party sites. These tests no longer work as xpcshell tests, since Fathom expects full layout and style information. The spirit of these tests is maintained by adding these pages to Fathom's training, validation, and testing corpora at 2bfcdf23dc. A few don't make it due to iframes which confound Fathom's capture tools, but the rest all succeed--and now improve the ML model as well as acting as tests. The training results after said integration reflect this improvement, which boosts testing precision and recall for every type.
* Add a mochitest to ensure the Fathom integration code can surface a decision that a field should not be autofilled. Decisions that go the other way are taken care of by the existing autofill tests.
Differential Revision: https://phabricator.services.mozilla.com/D100141
Get a version which will throw a specific error when isVisible() is run on elements that aren't in a window.
Some of the xpcshell tests crash because they transit through the codepath that calls Fathom, even though they don't do anything with its output. Fathom gets cranky and throws an exception because the elements it's evaluating don't live within a window object (an artifact of the test harness). This lets us swallow that exception and no others.
Differential Revision: https://phabricator.services.mozilla.com/D107906
We need it from both FormAutofillHeuristics and CreditCardRuleset, and it would make a circular import otherwise: FormAutofillHeuristics -> CreditCardRuleset -> FormAutofillHeuristics.
Differential Revision: https://phabricator.services.mozilla.com/D100140
Implement an observer to wait for correct window events in order to restore tab
content. Non-SHIP code restores about:reader scroll position after receiving
"AboutReaderContentReady" event, so to achieve the same thing with session
history in parent enabled, we can wait for "AboutReader:Ready" event.
Differential Revision: https://phabricator.services.mozilla.com/D108712
