We check surrogate pair at specific index in `nsTextFragement` in a lot of
places. This requires boundary check of the index so that it can cause
security issue and crash reason with simple mistake, and also it steals
your time to understand the code what it does especially when it's a
part of an `if` condition.
Therefore, this patch adds new API to `nsTextFragment` and makes the all
surrogate pair handlers of `nsTextFragument` use new API.
Differential Revision: https://phabricator.services.mozilla.com/D39689
--HG--
extra : moz-landing-system : lando
When privacy.spoof_english = 2, we should hide the user's
locale in content. So we use en-US default strings for HTML
form elements, such as a Submit button.
We also force GetLocalizedEllipsis() to always return the
ellipsis used by en-US.
Differential Revision: https://phabricator.services.mozilla.com/D35815
--HG--
extra : moz-landing-system : lando
This method makes the following patches simpler and avoid duplicating same
code.
The utility method retrieves `TextEditor` from `HTMLInputElement` and
`HTMLTextAreaElement`. However, this won't cause creating corresponding
editor because when it calls from `TextEditor`, editor shouldn't be created
at that time due to requiring another reflow. Additionally, it's not
necessary for `nsTextFrame` because without `TextEditor`, all characters
in password field should be masked.
Differential Revision: https://phabricator.services.mozilla.com/D38008
--HG--
extra : moz-landing-system : lando
All callers treat '%' being found the same as not having consumed all the input,
so we can just stop consuming it.
Differential Revision: https://phabricator.services.mozilla.com/D36214
--HG--
extra : moz-landing-system : lando
For avoiding confusion between API of `nsRange` and `StaticRange`, I'd like to
rename `nsRange::CreateRange()` to `nsRange::Create()` because
`StaticRange::CreateStaticRange()` is too long name and
`StaticRange::CreateRange()` sounds odd. This patch renames it and changes
related methods to template methods to avoid runtime cost of temporary
`RawRangeBoundary` instance creation.
Differential Revision: https://phabricator.services.mozilla.com/D35141
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This StorageAccess code tells callers that they must partition third-party
storage, or deny storage access if that is not possible.
Differential Revision: https://phabricator.services.mozilla.com/D29740
--HG--
extra : moz-landing-system : lando
This StorageAccess code tells callers that they must partition third-party
storage, or deny storage access if that is not possible.
Differential Revision: https://phabricator.services.mozilla.com/D29740
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
