We already have browser_autoFill_preserveCase.js, which checks that we preserve case. This patch extends it to check a couple of more things: autofill is restored on up/down, and the user's input is restored when no result is selected.
Differential Revision: https://phabricator.services.mozilla.com/D24273
--HG--
rename : browser/components/urlbar/tests/browser/browser_autoFill_preserveCase.js => browser/components/urlbar/tests/browser/browser_autoFill_preserve.js
extra : moz-landing-system : lando
Added a new state `requestsStarted` in the timing-marker.js reducer which is initialized with the time a new reload (when persist logs in enabled) is triggered. Used this parameter to calculate the `DOMContentLoaded` and `load` metrics in the StatusBar.
Differential Revision: https://phabricator.services.mozilla.com/D23848
--HG--
extra : moz-landing-system : lando
A possible alternative would be to have the main thread already paint a
displayport at the target position of a requested visual update as part of
the same transaction that requests the update.
There are a couple of reasons we may not want to do that:
1) APZ could reject the requested visual update under certain conditions,
e.g. if there is a higher-priority layout update.
2) It would break the property that the displayport in the main thread's
scroll metadata is relative to the scroll offset in said metadata.
Various places assume this and untangling that seems tricky.
This does mean that if the main thread requests a visual update to "far away"
(outside the existing displayport), we can get temporary checkerboarding
before the content at the target position is painted. However, it's
straightforward for callers to work around that, by changing the layout scroll
offset _and_ scheduling a visual update if they wish to visual-scroll far
away.
Differential Revision: https://phabricator.services.mozilla.com/D23902
--HG--
extra : moz-landing-system : lando
We were rounding up for growing the nursery, rounding down for shrinking.
If we round nearest in all cases then we can also round our minimum and
maximum size parameters the same way.
Differential Revision: https://phabricator.services.mozilla.com/D22287
--HG--
extra : moz-landing-system : lando
The nursery capacity included the usable size of nursery chunks. However
it'll simplify the parameters for the nursery size if it uses whole
nursery chunks, so include the chunk trailers in the nursery capacity.
This means changing the subchunk calculations slightly to handle the
sub-chunk/whole-chunk mode transitions.
Differential Revision: https://phabricator.services.mozilla.com/D22286
--HG--
extra : moz-landing-system : lando
This change moves some details of maybeResizeNursery() into a new function
that will resize the nursery in one of the situations where the nursery has
a fixed size.
It also simplifies the clamping code.
Differential Revision: https://phabricator.services.mozilla.com/D22285
--HG--
extra : moz-landing-system : lando
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
Newer versions of rust come with a specialized arm target that matches
more closely our armv7 targets (with neon and thumb2), so use that when
possible.
Depends on D24324
Differential Revision: https://phabricator.services.mozilla.com/D24325
--HG--
extra : moz-landing-system : lando
We were rounding up for growing the nursery, rounding down for shrinking.
If we round nearest in all cases then we can also round our minimum and
maximum size parameters the same way.
Differential Revision: https://phabricator.services.mozilla.com/D22287
--HG--
extra : moz-landing-system : lando
The nursery capacity included the usable size of nursery chunks. However
it'll simplify the parameters for the nursery size if it uses whole
nursery chunks, so include the chunk trailers in the nursery capacity.
This means changing the subchunk calculations slightly to handle the
sub-chunk/whole-chunk mode transitions.
Differential Revision: https://phabricator.services.mozilla.com/D22286
--HG--
extra : moz-landing-system : lando
This change moves some details of maybeResizeNursery() into a new function
that will resize the nursery in one of the situations where the nursery has
a fixed size.
It also simplifies the clamping code.
Differential Revision: https://phabricator.services.mozilla.com/D22285
--HG--
extra : moz-landing-system : lando
NS_STATE_IS_OUTER_SVG is redundant, we clean it up and use
nsIFrame::IsSVGOuterSVGFrame() instead.
Differential Revision: https://phabricator.services.mozilla.com/D24330
--HG--
extra : moz-landing-system : lando
Disable the following tests for windows10-aarch64:
- test_enterjit_osr.js
- test_feature_mainthreadio.js
They were likely intermittents at first, but as of recent try push noted below these tests are failing consistently.
Differential Revision: https://phabricator.services.mozilla.com/D24413
--HG--
extra : moz-landing-system : lando
This patch shouldn't have any functional effect. It's motivated by
some changes needed to implement clip masks in pixel local storage,
but these are also general improvements that stand alone. Specifically:
- Remove clip_task_index from the global PrimitiveHeader struct.
In most cases, the clip task is supplied in the BrushInstance
structure, so it makes no sense to have this as a common field,
where it is generally unused. Instead, there is now an extra
'user data' field available in the PrimitiveHeader. Non-brush
shaders (text_run and split_composite) use that extra field to
store the clip task address, while the brush shaders gain an extra
(currently unused) user data field.
- In turn, this means there is no need to unconditionally try
and retrieve the first clip task address for a primitive
during batching. This was previously used to initialize the
PrimitiveHeader structure.
Differential Revision: https://phabricator.services.mozilla.com/D24312
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::PrepareToDispatchEvent()` checked whether the
given event is a trusted event or an untrusted event, but
`PresShell::EventHandler::PrepareToDispatchOntextMenuEvent()` didn't so.
However, now, both of them don't need to check it. Therefore, we can merge
them.
Differential Revision: https://phabricator.services.mozilla.com/D24132
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler` shouldn't be used to dispatch untrusted event.
However, it checks whether the given event is trusted or untrusted somewhere
and that makes the code harder to understand. So, it should check each event
only with `MOZ_ASSERT()` or `MOZ_DIAGNOSTIC_ASSERT()` instead. Then,
developers can trust the event is always a trusted event.
Differential Revision: https://phabricator.services.mozilla.com/D24131
--HG--
extra : moz-landing-system : lando
The current standard requires some functions to have no own `name` property at
all; they instead inherit `Function.prototype.name`, which is `""`. However,
V8 and JSC both already do what we do, so we're working to change the standard
instead of changing our behavior. See
<https://github.com/tc39/ecma262/issues/1049>.
Differential Revision: https://phabricator.services.mozilla.com/D23394
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
