Previously we called `ProcessCrossOriginEmbedderPolicy` in
`nsHttpChannel::ContinueProcessResponse1`, but we only loaded the cached
response headers in `ContinueProcessResponse3`, meaning that we incorrectly
reported a missing header for the revalidated resource.
This change moves the header checking calls to `ContinueProcessNormal` and
`AsyncProcessRedirection` instead, so they get executed after processing
the cached headers.
Differential Revision: https://phabricator.services.mozilla.com/D125184
mPrintTarget can be nulled out and the caller needs to deal with null
returns already, so this should address the crash.
Differential Revision: https://phabricator.services.mozilla.com/D137473
This is a sufficient fix to handle this case, we should definitely
invalidate the dirty rect validity if the compositor surface count
has changed.
There are likely other cases where the surface count remains the same
but we also need to invalidate dirty rect validity (we can handle
these as follow ups and/or as we encounter other cases).
Differential Revision: https://phabricator.services.mozilla.com/D135462
These assertions are already diagnostic asserts, and this will make
failures to check Maybe into safe crashes rather than security bugs on
all branches.
A failure to check Maybe is more dangerous than a null pointer
dereference, as the generated code will produce a valid reference to
uninitialized data rather than a null reference which should safely
segfault.
Differential Revision: https://phabricator.services.mozilla.com/D138208
Our typing interactions separate typing into sessions. If you haven't typed for longer than a
certain period of time we count the previous session as over and start afresh. Any sessions
containing just one keypress are discarded, the rest are aggregated.
In our automated tests we want to test that this detection of a new session of typing works and our
only way to do that is to actually delay the test for longer than the maximum time between
keypresses. So the test runs fast we reduce the maximum time pref to 50ms.
Unfortunately I've experimentally seen that in CI on debug and asan builds that when not testing
this aspect and sending a sentence of characters we can still occasionally see delays of over 50ms
between individual characters. If this delay happens between the first and second character or the
last and last but one character then we end up with a typing session with a single character in it
which gets discarded leading our interaction metrics to be short one keypress.
This patch removes the reduced preference value for general tests and sets a value of 150ms for the
few tests where this matters.
Differential Revision: https://phabricator.services.mozilla.com/D139039
The failing test is the only one that verifies reload scenarios with respect to history metadata interactions.
I haven't been able to find a solution to this intermittent, I am remove the specific test that's failing and creating a bug to test reload scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D137477
The test test_typing_and_reload() was failing, I believe because without waiting for target url in browserLoaded(), we would proceed on the about:blank load and the new interaction write would race the test.
Differential Revision: https://phabricator.services.mozilla.com/D136186
This fixes the root cause of the intermittent failure (missing keystrokes) -- the function to send keys was not strictly synchronous.
We now wait for the input field to be populated before we proceed.
Differential Revision: https://phabricator.services.mozilla.com/D128409
In the scenario where we navigate to a second url immediately after typing we intermittently lose a keystroke on some builds.
I haven't been able to trace down how this happens, however waiting for the next tick in the event loop after each step appears to resolve the intermittent.
Differential Revision: https://phabricator.services.mozilla.com/D127885
The first subtest is already annotated as failing on all platforms. My
patch seems to have changed timing in a way such that the second test
also fails in non-macOS platforms.
I tried to reproduce the failure locally and investigate a bit more, but
couldn't. The test doesn't seem particularly racy, off-hand, other than
it using a timer which at best should make the test unexpectedly pass,
not unexpectedly fail...
The other thing that looked suspicious is that the test was waiting for
the load event of the main window, not of the popup it opens (which I
think might be unintended). However that also doesn't make the
failure reproduce here.
Differential Revision: https://phabricator.services.mozilla.com/D120204
If the visual viewport offset is not set on the presshell then calling GetVisualViewportOffset returns (0, 0). This then causes us to introduce an incorrect offset between the layout scroll offset and the visual viewport offset that didn't exist before.
Logically we want to treat an unset visual viewport offset as the layout scroll offset.
Other possible fixes:
-make PresShell::GetVisualViewportOffset return the layout scroll offset if a visual viewport offset is not set
-make this if conditional on a visual viewport offset already being set
-the combination of the two above
All of these fail some tests on try server. I haven't investigated why. If we want to go with any of those potential fixes in the future then this patch is a step on the way there
Differential Revision: https://phabricator.services.mozilla.com/D137873
Having 3 regular domains to test fission scenarios will help migrating to https-first for DevTools mochitests.
example.org and example.com are both available in http and https, but example.net is only available in http for now.
This patch was created by adding https://example.net to build/pgo/server-locations.txt and then running `./mach python build/pgo/genpgocert.py`
Differential Revision: https://phabricator.services.mozilla.com/D127922
