The test here used a face with `src: local(Arial);`, while the reference file used `font-family: Arial, sans-serif`;
but these may not reliably result in the same behavior. The `@font-face` rule looks up a specific *face*,
and if that face is not found, the test will fall back to the browser's default font; but the reference might
get a *different* result if, for example, a fontconfig alias/substitution rule is present that maps Arial to
a different sans-serif than the browser's default.
So instead of trying to use a local font lookup to provide the metrics contrast with Ahem, this patch specifically
loads a second font resource (in both the testcase and reference) to provide consistent behavior.
Differential Revision: https://phabricator.services.mozilla.com/D116452
We have a couple of tests that fail on tryserver on certain platforms (though they pass for me locally),
apparently because the glyph measurements used to support the various glyph-related metrics may be
affected by resolution and/or hinting settings. So these are annotated as fuzzy for now.
If we undertake a reimplementation of font metrics to better harmonize behavior across platforms
(a longstanding wish!), perhaps we'll be able to eliminate these discrepancies.
Differential Revision: https://phabricator.services.mozilla.com/D116282
Clearing debugger state from onTargetAvaible should be fine,
as soon as we do it immediately.
But doing it from DOCUMENT_EVENT will-navigate may help
if we get some debugger related resources while the target is still attaching on the client.
It should better ensure that state is cleared at the right time, the earliest right time.
Differential Revision: https://phabricator.services.mozilla.com/D116810
`connect` and `willNavigate` actions are redundant, except for the isWebExtension argument.
And calling `connect` late, after a few async code make us reset redux state way too late.
Some sources/breakpoints could be processed before and we end up having confusing state.
Differential Revision: https://phabricator.services.mozilla.com/D116809
Ion has an LICM pass on MIR. It contains adequate checks to ensure that
hoisting MIR nodes maintains correctness. But it is almost completely
indiscriminate when it comes to the question of which nodes are profitable to
hoist. It will hoist any (valid-to-hoist) node, with the sole exception of
constants that are used by non-invariant nodes. In particular, it will hoist
nodes from arbitrarily low-probability paths within the loop body. This is
believed to be the cause of the factor-of-3 perf regression shown in bug
1708381.
This patch:
* Disables LICM for any loop with more than 100 blocks in the body or that
contains an MTableSwitch instruction with more than 25 successors. Either
of these guards individually fixes the original 1708381.
* Adds comments explaining the rationale for the above two thresholds, plus a
tiny amount of profiling data that suggests they are reasonable values.
* Fixes some indentation and wording in the debug printing, so as to make it
easier to read.
The perf effect on most wasm inputs is somewhere between nonexistent and very
small. The above limits are pretty generous and, at least for wasm, most
loops are fairly small and so will still qualify for LICMing. For the
Embenchen wasm perf suite, the geomeans for instruction count, data reads and
data writes, in JIT-generated code, fall by 0.10%, 0.19% and 0.13%
respectively.
Differential Revision: https://phabricator.services.mozilla.com/D116582
This patch makes the previously created handler method to virtual (derived from
`EditorBase`), and makes `TextEditor` override it.
Depends on D116801
Differential Revision: https://phabricator.services.mozilla.com/D116802
Actually, we set auto-capitalize flag if current `<input>` element isn't text
due to bug 871884.
Most 3rd party keyboard ignores this flag if it is password. But Samsung's
default keyboard uses this flag even if this is password.
So we shouldn't set auto-capitalize flag if `<input>` element is password.
Also, we also set this on `type=email` and `type=url`. But when I check Chrome
behaviour, they don't set this flag on these types. So I would like not to set
this flag to these types too.
Differential Revision: https://phabricator.services.mozilla.com/D115677
`TextEditor::OnDrop()` handles both cases, in `TextEditor` and in `HTMLEditor`
because the common part is too complicated to duplicate. However, most
different part is inserting the dropped items part. So, let's make them
into a virtual method.
In this patch, creating a method only in `HTMLEditor` and moves the part
into it.
Depends on D116569
Differential Revision: https://phabricator.services.mozilla.com/D116801
https://accounts.firefox.com runs the following script.
```
input.addEventListener("keyup", () => {
// Update <datalist>
temporaryElement.focus();
input.focus();
}
```
Since `input.focus()` is called, `GeckoViewSupport` sends current value of
focused `<input>` element to `GeckoEditable`, but we don't cancel previous
text transaction unfortunately. Then it may cause unexpected behaviours such
as reported issue.
So we should dispose previous text transaction when getting new focus.
Also it is difficult to write unit test for this. Because,
- Mochitest cannot test this since this issue is native IME behaviour.
- No way to create this timing on geckoview-junit.
Differential Revision: https://phabricator.services.mozilla.com/D116681
xpcshell tests can be run on Android since bug 1567341 was fixed, so
enable them to ensure that we have test coverage on Android.
`_TEST_FILE` contains file names in remote xpcshell tests (Android),
so `_TEST_NAME` had to be used instead.
`ok` had to be replaced with `Assert.ok` because `ok` is only available
later, after the import of `AddonTestUtils.jsm`.
Unrelated gfx tests are still failing, filed follow-up as bug 1714673.
Differential Revision: https://phabricator.services.mozilla.com/D116419
We always attempt to zoom to the width of the element we double tap on, cutting off the top/bottom of the element if necessary. For elements that contain text that are relatively quite tall this is good. But for things like images which are not really that tall, but just happen to have a taller aspect ratio then the viewport it is not ideal.
Differential Revision: https://phabricator.services.mozilla.com/D114582
This fixes two issues: the overlay 'steals' clicks when displayed for PiP for pinned tabs,
and for unpinned tabs hovering the (invisible) overlay on the icon alters the status text
display (to 'mute tab') - but clicking does not have the effect described by the status text.
Differential Revision: https://phabricator.services.mozilla.com/D115500
We don't offer API splits any more, and with the separation of GeckoView with
the rest of the front-end it's increasingly unlikely that we will in the
future.
This change makes it so that the build name doesn't contain the API version so
that we can update it without breaking all the automation that relies on the
build name.
Differential Revision: https://phabricator.services.mozilla.com/D114369
The goal is to make it easier for admins to have a generic way to
locate Firefox for uninstall, without needing to know the target
version to uninstall. The version in the `DisplayName` is extraneous:
it's in the `DisplayVersion` field, and users can see it when you
click on it in "Add/Remove Programs". Automated consumers may prefer
to read the `Comments` field of the Firefox uninstall data instead,
which remains identical to the `DisplayName` before this change.
Differential Revision: https://phabricator.services.mozilla.com/D116648
