When caret is not moved but selection change command is fired, it means that
the caret is already set to start or end of editing host. In this case, we
should stop keeping link style for new inserting content because otherwise,
user cannot exit from the first or last link with arrow keys.
Differential Revision: https://phabricator.services.mozilla.com/D101003
Although different from the other browsers' behavior, our traditional behavior
might be better than them because the behavior on the other browser does not
allow users to insert new content at start nor end of a link.
However, we can relax more about keeping traditional behavior for web-compat.
Perhaps, only when caret is moved from the other side of first or last character
in the link and moves caret to the edge of the link with arrow key, we should
allow users to modify the link text.
Otherwise, e.g., `Home` and `End` key press should make it stop keeping the
link style. This helps advanced users who are familiar with keyboard navigatin
in editor.
Note that this patch also changes the condition which checks
`aReason & nsISelectionListener::KEYPRESS_REASON` to check also
`nsISelectionListener::COLLAPSETO_START_REASON` and
`nsISelectionListener::COLLAPSETO_END_REASON` because all of them are
set by `nsFrameSelection::MoveCaret` exclusively.
https://searchfox.org/mozilla-central/rev/a0ccd492719b1ad2106f6456549be62a76f45acb/layout/generic/nsFrameSelection.cpp#738,741,745
Therefore, they should be treated as same as a key press.
Note that they are also set by `Selection::CollapseToStart` and
`Selection::CollapseToEnd` too. But a following patch will add a new
reason to notify selection listeners of caused by JS. So, the problem
will be fixed by the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D101002
When mouse button is clicked outside a link element but caret is positioned
start or end of the link, our traditional behavior keeps inserting new content
into the link. But this is different from the other browsers, and it does
not make sense to treat such selection change is intended to keep typing in
the link element.
Therefore, this patch makes `TypeInState::OnSelectionChange()` handle
selection change reason is `mousedown` and `mouseup` cases. However,
it cannot know whether the event was fired in the parent link element or
not. Therefore, this patch makes `HTMLEditorEventListener` notifies
`TypeInState` of mouse events via `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D101001
They were designed for object resizer and grabber to move absolutely positioned
element. Therefore, they should have better name to explain what they do.
Then, we can create event listener methods for generic cases.
Differential Revision: https://phabricator.services.mozilla.com/D100999
Currently, the test checks the result only in `contenteditable`, but I'd be
better to do same tests in `designMode` editor too.
Additionally, for detecting regressions of the following patches, it should
check the result of 2nd typing too because inserting text into end of a link
element may cause unlink it.
Differential Revision: https://phabricator.services.mozilla.com/D100997
This patch converts `GeckoChildProcessServices.java` into a jinja template.
We also add an overlay generated from a jinja template for `AndroidManifest.xml`
that provides the definitions for content process services.
Note that even though Gradle supports simple substitution of variables in
manifests, I opted not to use that functionality. Since we need the more
powerful template functionality that jinja provides, I felt that having multiple
ways to substitute information into the manifest would be confusing, so we're
using jinja exclusively.
Differential Revision: https://phabricator.services.mozilla.com/D82578
* We add a config option for setting the number of content services;
* We add a config option to indicate whether content services should be isolated.
This one is just a `project_flag` since it doesn't really need the ability to
be overridden; it's something whose default we would want to flip when the
time comes;
* We set a dependency so that mobile/android/base/pre-export is executed;
* We add the `gen_from_jinja.py` script which is mostly just a dumb shim that
takes the input template and the config arguments, instantiates jinja,
generates the final output, and dumps it to the output fd;
* We add the requisite `moz.build` statements to generate the manifest overlay
and the service definitions;
* We update `build.gradle` so that Gradle knows to look for the generated files
when building the apk.
Differential Revision: https://phabricator.services.mozilla.com/D82577
These are the minimum changes that we need to make to common build system code
to allow us to generate files during pre-export.
We add a `required_before_export` flag to `GeneratedFile` to indicate when a
particular file must be generated in `pre-export`. We set that flag when there
are `.jinja` input files and we're configured for a GeckoView build, otherwise
it is set to `False`.
Then the recursive `make` backend assigns any `GeneratedFile`s that have
`required_before_export` set to run in the `pre-export` tier.
Differential Revision: https://phabricator.services.mozilla.com/D82576
There's a macOS-specific wrinkle for browser/ that populates the
`.app` directory. This makes that happen as part of `mach
package-multi-locale`. It's the equivalent, I suppose, of `mach
android assemble-app` for Desktop.
Differential Revision: https://phabricator.services.mozilla.com/D101502
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
The TabDialogBox will manage two separate SubDialog managers at the tab and content level. Dialogs managed at the tab level will always be on top of content ones and should always receive focus first when tab switching or refocusing the window.
Differential Revision: https://phabricator.services.mozilla.com/D100066
This test spams the same assertion either 4 or 6 times, with this variation
probably being due to an extra reflow which we sometimes incur due to a
font-fallback task having coincidentally just completed, as described in
https://groups.google.com/g/mozilla.dev.platform/c/VBh6oLm4EbQ/m/dbaJcAe6BgAJ
Previously the test was annotated as asserting exactly 4 times, but now we
need to allow for it to sometimes assert 6 times instead.
Differential Revision: https://phabricator.services.mozilla.com/D101506
This patch ensures that the global print_to_filename pref is checked
when initializing print settings from prefs.
It also fixes a regression which was preventing the Linux system dialog
from correctly reading its printer-specific print_to_filename prefs.
Differential Revision: https://phabricator.services.mozilla.com/D98975
This will reduce memory footprint when there are multiple @font-face rules with the same unicode-range descriptor,
which is common when, for example, a site loads several styles of a family, all with the same character repertoire.
Differential Revision: https://phabricator.services.mozilla.com/D101411
glean_parser depends on `iso8601`, but only on Python <= 3.6.
Add the `iso8601` hash to our frozen dependency hash list accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D101494
In rare cases, WR can invalidate a tile, but still compute a dirty rect that doesn't intersect that tile.
flush_composites expects all updated tiles to have recorded at least one overlap (for itself), so we set this manually (as we in the normal path after the early return).
Differential Revision: https://phabricator.services.mozilla.com/D101427
Since zstandard has native code that must be compiled, and that code
uses Python headers, we should be installing those headers as part
of bootstrap.
Most users will have these packages on their machines through various
other means (notably installing `pip`, ie `sudo apt install python3-pip`),
but since it is possible to avoid a pip installation (for example
by installing Mercurial through `yum` and then running bootstrap
immediately after cloning) we should specify these packages as required
by bootstrap.
Differential Revision: https://phabricator.services.mozilla.com/D101479
I focused this on fixing what the bug describes: updating the doc for our new
development model where we create experimental APIs inside each extension
instead of landing APIs in mozilla-central. There are a number of other changes
I want to make to this doc but didn't here in order to keep it scoped. I filed
bug 1684069 for those other changes. I can imagine that some of the changes that
this patch makes will be overidden or updated by that bug.
This also fixes a broken link or two.
Differential Revision: https://phabricator.services.mozilla.com/D100417