Surprisingly, `Document::ExecCommand()` may be called when there is no
corresponding `nsPresContext`. Then, `nsContentUtils::GetHTMLEditor()`
crashes because it does not check whether the argument is `nullptr` or not.
This patch makes it check whether `aPresContext` is `nullptr` or not, and
makes `Document::ExecCommand()` not try to look for an editor when its
`GetPresContext()` returns `nullptr`. This means that we cannot send
proper `nsIPrincipal` object to the editor in this case. But I'm not sure
how it's important and whether editor can or cannot modify the DOM tree
actually.
Differential Revision: https://phabricator.services.mozilla.com/D34505
Most commands are dispatched only when the `document` has `contenteditable` or
in `designMode`. In such case, command context is considered with the following
order:
1. `HTMLEditor` for the document.
2. `TextEditor` if the document has focus and it has `TextEditor`.
3. Other command controller table associated with window or DocShell.
In the case of #1 and #2, `ExecCommand()` can use `EditorCommand` directly
and we only need to send subject principal to the editor only in these cases.
In the case of #3, we need to fall back to traditional path. There are 2 paths:
1. If it's "paste" command, handle it with `nsCommandManager` to dispatch
"paste" event.
2. If it's "cur" or "copy", handle it with `DocShell` to dispatch "cut" or "copy"
event in the window or focused sub-document.
Note that clipboard "cut" and "copy" commands are special cases. Only them
were handled by `DocShell` instead of `nsCommandManager` This difference
caused making active element's `TextEditor` is preferred rather than
`HTMLEditor`. Although this behavior is better than our traditional behavior
because Chromium works as so. But for now, we should keep our behavior.
Finally, this patch makes `ExecCommand()` creates `nsCommandParams` instance
since now, `EditorCommand` class can take only necessary parameter without it.
Differential Revision: https://phabricator.services.mozilla.com/D29632
Right now there's some duplicated code with the focus manager and the
DOMWindowFocus event.
Android didn't handle the new framefocusrequested event, so the test-cases in
bug 416771 still didn't work there.
I think using the focus manager codepath everywhere is preferable. I confirmed
manually that the stuff that sent DOMWindowFocus events still works as expected
with this patch (i.e., switching to the right tab when you click on a
notification, etc.).
This fixes it so that it works in Fennec, and it sends the focus events right in
GeckoView Example (i.e., we get here[1] properly).
The snippet that Snorp provided on IRC to implement the "bring activity to
front" stuff (`startActivity(getIntent())`) didn't actually work for me, but I
confirmed that the right message is sent when the focus is requested, and that
we get there.
[1]: https://searchfox.org/mozilla-central/rev/952521e6164ddffa3f34bc8cfa5a81afc5b859c4/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#503
Depends on D32353
Differential Revision: https://phabricator.services.mozilla.com/D32354
It's only moved around, but not actually used anywhere.
I have no idea what this was supposed to control in the past but it doesn't seem
useful to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D33393
The only protocol that can't be created off the main thread at the moment is
moz-extension, and that can be handled at a later time.
Differential Revision: https://phabricator.services.mozilla.com/D30713
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
I was clearly trying to do that in bug 882653 part 3 and failed to. Our
current behavior of passing two args to this error message (which only takes
one arg) is silly, and the only thing that makes it at all sane is that we only
use it in class hooks, which can never have the wrong sort of object, so it's
unreached code.
The comment cleanup is just to make the role of CGAbstractBindingMethod. and
the validity of the changes to it, clearer.
Differential Revision: https://phabricator.services.mozilla.com/D32478
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
GetNodeDepth() is a special version for ResizeObserver to get the depth
of node (across Shadow DOM). Based on the comment in D27615, it's better
to move it into ResizeObserver.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D28736
