If a `<br>` element follows a visible thing and there is no visible content
between it and following block boundary (both child's and parent's), it's
called as "invisible" BR element at Mozilla.
Selection API can put caret after it but before the following block boundary
and of course, user may be able to put caret at there if the browser has a
bug like <https://bugzilla.mozilla.org/show_bug.cgi?id=1738193>.
Even in this case, user can type something if it's in editable content, and
even though this is an edge case, it's safe to get same result in any browsers
since web apps may put caret there accidentally.
The expected results are based on Blink's behavior and Gecko fails the cases
if the following block boundary is of a child block. However, no patch for
Gecko for now.
Differential Revision: https://phabricator.services.mozilla.com/D130137
Many users report that GeckoView returns non-coarse value for primary pointer
capabilities. Actually, we assume that primary pointer device is 1st device by
`InputDevice.getDeviceIds`, but some mobile devices seems not to return touch
screen as 1st item according to user reports.
Also, Android's `InputDevice` API doesn't define what is primary pointer
device, so we cannot assume primary pointer device well.
Other implements are,
- Chrome returns coarse if something input device has coarse capability.
- Firefox for Windows seems to return coarse if it is tablet mode.
So we should return coarse as primary pointer capability when having touch
screen, like Chrome.
But there is still another issue.
When I check some devices (including Android VM on Chrome OS), even if no touch
screen, the `InputDevice`'s source may has `SOURCE_TOUCHSCREEN`. Chrome checks
that fine pointer at first, then it checks coarse pointer. But current GV is
coarse pointer at first. Since the `InputDevice`'s source may have both
`SOURCE_MOUSE` and `SOURCE_TOUCHSCREEN` on touchpad/mouse, GV returns different
result. So we shouldn't check `SOURCE_TOUCHSCREEN` at first.
Differential Revision: https://phabricator.services.mozilla.com/D129901
This is necessary for two reasons:
1. Leaf text attributes and default text attributes are cached separately, since the caller can choose whether to include defaults or not. This means merging them together.
2. Methods for retrieving attributes currently return a non-const AccAttributes. We might be able to change this in future for some of them, but I didn't want to deal with that in this work.
Differential Revision: https://phabricator.services.mozilla.com/D129472
This uses TextLeafPoint.
This patch includes support for ATK, IA2 and XPCOM.
As with TextAtOffset, HyperTextAccessible calls the base implementation if the cache is enabled, but otherwise uses the old implementation for now.
Differential Revision: https://phabricator.services.mozilla.com/D129469
This supports both fetching text attributes and finding the start of attribute runs, but only for LocalAccessible.
Support for RemoteAccessible will be added in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D129468
This will be used later to check whether text attributes are different between two Accessibles.
I added this as a method instead of operator== because callers always hold a pointer to AccAttributes, and *a1 == *a2 is weird and will probably lead to mistakes.
This required adding operator== for our value structs.
Differential Revision: https://phabricator.services.mozilla.com/D129467
Brief recap:
Before we have blocking autoplay, we had a feature which will delay media from start if the tab hasn't been visited by users, in order to prevent an unvisited background tab suddenly play sounds, which is annoying and might be unexpected to users.
In this patch:
The attribute we use to check whether we need to delay media is on the outer window, which is not Fission compatible if the top level window and its child windows are on the different process.
If the top level window has been visited, then all its child window should follow the same result. Therefore, we need to move the attribute to the browsing context in order to sync it across different windows.
Differential Revision: https://phabricator.services.mozilla.com/D128126
The optional `log_handle` argument was only used by:
* Configure, but the output was always dumped to stdout and *not*
`config.log`. The manual logging _was_ used to handle encoding issues,
but those are likely invalidated by the Python 3 migration.
* `./mach doc`, where we were putting virtualenv setup into stderr,
which seems incorrect. The commit adding it doesn't explain why it's
the case, but I'm guessing it shouldn't be too risky to remove.
Additionally, `log_handle` was used very inconsistently: for example,
running `install_pip_package()` would _not_ use `log_handle`.
So, removing `log_handle` removes a bit of abstraction leakage.
Differential Revision: https://phabricator.services.mozilla.com/D129298
Mach already verifies the Python version during initialization.
Maintaining a second version check can be tough to keep up-to-date, as
we're already seeing due to the obsolete Python 2 check.
Differential Revision: https://phabricator.services.mozilla.com/D129297
Now that are prioritizing system over virtualenv site-packages, the
system `pip` is sometimes being used instead.
This is causing issues when the system pip is set up in a
distro-specific way, such as when "debundled":
https://github.com/pypa/pip/blob/9.0.1/pip/_vendor/__init__.py#L53-L61
However, if we vendor `pip`, `setuptools` and `wheel`, and ensure that
they're prioritized in the `sys.path` before anything is imported from
the system, then we can ensure that we're using a modern `pip` _and_
sidestep system-specific pip weirdness.
Note that `pip-compile`'s `--allow-unsafe` flag is not as dangerous as
it sounds.
There's confusion among maintainers about its origin:
https://github.com/jazzband/pip-tools/issues/522
Additionally, it's going to be enabled by default in a future
`pip-tools` release. So, it's not scary for us to embrace here.
Also, heads up that the "pip outdated warning" no longer needs
to be manually silenced, since pip avoids that code path when
not running from an "installed" context.
Differential Revision: https://phabricator.services.mozilla.com/D127182
The previous behaviour was to:
* Never add a `pthfile` to the Mach virtualenv, and
* Always add Mach's paths to the `sys.path` when Mach initializes
However, this meant that `pip` would needlessly install packages
that already exist in the vendored environment.
Tweak `pth` behaviour so that `pip` behaves more efficiently.
Differential Revision: https://phabricator.services.mozilla.com/D120402
As we leverage the Mach environment more, it becomes increasingly
important that it isn't out-of-date on developer machines.
Add an `up_to_date()` check during Mach initialization.
To minimize the cost to startup, I'm skipping the "pip list" check.
This change required moving `virtualenv` from `mozbuild` to `mach` to
make it available during the early stage of Mach init.
Differential Revision: https://phabricator.services.mozilla.com/D127144
Inline a variable used once, and ensure that `old_env_variables` is
defined consistently before the `finally` block runs to satisfy an
intellisense warning.
Also, ensure that a wide comment is shuffled underneath the line limit.
Differential Revision: https://phabricator.services.mozilla.com/D129296
Now that packages are consistently installed in a dedicated
`pip install` process, we can remove our funky re-execution of
`virtualenv.py`.
Since this re-execution was the only case in which `virtualenv.py`
was directly invoked by Python, we can remove the `__main__`-handling
block.
Also, now that `virtualenv.py` always is interpreted with its needed
modules in-scope, the deferred `MachEnvRequirements` import can be
moved to the top of the file.
Differential Revision: https://phabricator.services.mozilla.com/D129295
`install_pip_package()` does some logic around not running pip if a
package is already installed.
However, this is redundant, because when building a venv, no packages
are installed.
Additionally, this was the constraint forcing us to populate the
virtualenv in a separate process from the one building it.
Differential Revision: https://phabricator.services.mozilla.com/D129294
