It waits a `scroll` event after synthesizing `PageDown` or `PageUp` key event
and it causes intermittent timeout if unexpected cases occurred randomly.
Therefore, we've not have enough hint to fix the existing intermittent timeout.
For making this bug forward, it should stop waiting a `scroll` event with a
`Promise`. Instead, it should check whether a `scroll` event fired or not
with a few times retry.
Differential Revision: https://phabricator.services.mozilla.com/D103014
Asynchronous font loading occurs during scroll position tests, it resets
scroll positions to 0. So, this causes intermittent failures in such tests.
Disabling the async font loading under `layout/base/tests` may not be proper
solution because some layout tests may work perfectly even if global reflow
may occur.
Therefore, this patch moves 2 tests which check scroll position to under
`dom/events/test` and disabling the async font loading since the global reflow
shouldn't be related to the tests under `dom/events`.
Differential Revision: https://phabricator.services.mozilla.com/D103013
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
Currently, we don't allow keyboard events synthesized for tests retrieve native
key bindings in content process. However, due to this, we cannot test keyboard
navigation, deleting per word, etc on Linux and macOS either with mochitest
or WPT. For making better compatibility with the other browsers, we should
write WPT more with the test driver. Therefore, we should allow keyboard
events synthesized for tests retrieve native key bindings.
On the other hand, if we make them retrieve customized keyboard shortcuts
in the environment, some developers may not be able to run tests locally without
resetting their customization. Therefore, this patch makes `NativeKeyBindings`
set "standard" shortcut keys on the platform instead of retrieving actual
shortcut key results.
If referring the default shortcut key bindings is not good thing for
WebDriver/CDP, perhaps, `TextInputProcessor` should have a new flag which can
refer customized shortcut keys even in content process. But I think that it
should be done in another bug because some edit commands are mapped forcibly
like this patch.
https://searchfox.org/mozilla-central/rev/c03e8de87cdb0ce0378c0886d3c0ce8bbf9dc44e/remote/domains/parent/Input.jsm#82-102
Differential Revision: https://phabricator.services.mozilla.com/D102877
The sendWheelAndPaint call returns before it's done all its work. The way
this test uses the function, it can advance onto the next testcase before
the previous sendWheelAndPaint is done and the callback is invoked. This
can cause one testcase to pollute the next one which seems inadvisable.
Waiting for the sendWheelAndPaint callback to be triggered ensures that
all the work sendWheelAndPaint is going to do gets completed before the
next testcase is processed.
Differential Revision: https://phabricator.services.mozilla.com/D103122
With crossorigin, empty value and no value are two different things, so
the link header parser needs to handle it.
Without this change the updated test would fail with two entries rather
than one getting returned from:
numberOfResourceTimingEntries("resources/dummy.css?link-header-crossorigin-preload2")
Differential Revision: https://phabricator.services.mozilla.com/D103570
This is an issue I found while going through this code and
writing/debugging a test for the bug at hand. Without this, the test in
the actual fix for this bug will fail to actually reuse the preloaded
stylesheet.
It seems reasonable to assume that the intersection of quirks mode
documents using link preload headers is small (and in that case we'd
parse the sheet twice, but oh well).
Differential Revision: https://phabricator.services.mozilla.com/D103567
This updates the repeat init data detection code in TrackBuffersManager to also
detect repeat video init data. This will also detect cases where the init
segment contains repeat video and audio init data if both the audio and video
are the same as the previous init data.
Differential Revision: https://phabricator.services.mozilla.com/D103174
This should be a strict refactor (no functional changes), but makes the
boundaries of the code doing the repeat check more clear. This code will be
updated in a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D103173
Instead of inserting all elements into OriginInfo array, and then removing
or skipping irrelevant entries, only insert the relevant ones in the first
place, using a new utility function template MaybeAppendOriginInfos.
Sort them by in least-recently used order according to the access timestamp.
Iterate over them to identify the threshold.
Finally, truncate the array to the threshold position.
Differential Revision: https://phabricator.services.mozilla.com/D101146
Extracts parts of CheckTemporaryStorageLimits into the following new private
member functions of QuotaManager:
* LockedGetOriginInfosExceedingGroupLimit
* LockedGetOriginInfosExceedingGlobalLimit
* GetOriginInfosExceedingLimits
* ClearOrigins
Differential Revision: https://phabricator.services.mozilla.com/D101145
I'll simplify all the popup-blocking setup in a follow-up, but this is
the low-risk change.
Need to add a test for this of course. Kinda baffled we did not have
any.
Differential Revision: https://phabricator.services.mozilla.com/D103571
Instead of inserting all elements into OriginInfo array, and then removing
or skipping irrelevant entries, only insert the relevant ones in the first
place, using a new utility function template MaybeAppendOriginInfos.
Sort them by in least-recently used order according to the access timestamp.
Iterate over them to identify the threshold.
Finally, truncate the array to the threshold position.
Differential Revision: https://phabricator.services.mozilla.com/D101146
Extracts parts of CheckTemporaryStorageLimits into the following new private
member functions of QuotaManager:
* LockedGetOriginInfosExceedingGroupLimit
* LockedGetOriginInfosExceedingGlobalLimit
* GetOriginInfosExceedingLimits
* ClearOrigins
Differential Revision: https://phabricator.services.mozilla.com/D101145
I'll simplify all the popup-blocking setup in a follow-up, but this is
the low-risk change.
Need to add a test for this of course. Kinda baffled we did not have
any.
Differential Revision: https://phabricator.services.mozilla.com/D103571
The dom::TypedArray type currently represents its length as uint32_t. Changing
that to size_t/uint64_t would cause problems (truncation) for many 'Length()' callers.
Instead of requiring a length check for each of those call sites, for now check for
and reject large array buffers and views in the generated bindings.
Code and tests are based on the implementation of the [AllowShared] attribute.
Additional tests for the new JSAPIs will be added as part of bug 1674777.
Differential Revision: https://phabricator.services.mozilla.com/D102912
The dom::TypedArray type currently represents its length as uint32_t. Changing
that to size_t/uint64_t would cause problems (truncation) for many 'Length()' callers.
Instead of requiring a length check for each of those call sites, for now check for
and reject large array buffers and views in the generated bindings.
Code and tests are based on the implementation of the [AllowShared] attribute.
Additional tests for the new JSAPIs will be added as part of bug 1674777.
Depends on D102911
Differential Revision: https://phabricator.services.mozilla.com/D102912
The JS CompileOptions used to load cache entries must be consistent with
eachother to avoid subtle and serious bugs. This adds additional checks and
makes more consistent use of `FillCompileOptionsForCachedScript`.
This patch is a refactoring and should not change any behaviour.
Depends on D103515
Differential Revision: https://phabricator.services.mozilla.com/D103516
For consistency with other uses of the ScriptPreloader, we ensure we use lazy
script source when compiling for the cache. This generates full bytecode for
the cache but also avoids saving a copy of the source. If the frame script
were to call Function.prototype.toString, the existing source-hook would load
it in the same way as the JSM loader. In practice, we avoid relying on this
in our chrome code. If we will not be writing to the cache, we can instead
compile with the JS syntax parser, similar to what we do for JSM loader.
Differential Revision: https://phabricator.services.mozilla.com/D103515
Masayuki Nakano
Andreea Pavel
Kartikaya Gupta
Emilio Cobos Álvarez
Randell Jesup
Bryce Seager van Dyk
Butkovits Atila
Simon Giesecke
Tom Ritter
smolnar
dluca
Emma Malysz
Daisuke Akatsuka
Barret Rennie
Jan de Mooij
Mats Palmgren
Narcis Beleuzu
Ted Campbell