Now, this method returns simply the result of of `IsMozBrowserElement()`.
In the old days, We used to have IsMozBrowserElement and IsMozBrowserOrApp,
where the latter was true if we had a mozapp or mozbrowser.
But with b2g removed, the app thing went away.
`IsMozBrowser()` is less used than `IsMozBrowserElement()`.
I think the former should be replaced by the later one.
Differential Revision: https://phabricator.services.mozilla.com/D61699
--HG--
extra : moz-landing-system : lando
This is being done to reduce the intermittent failures we see in this test.
There are other non-intermittent tests that measure the specific number of
pixels traveled by mousewheel events. The focus of this test seems to be
"Ensure that mousewheel scrolling and zooming are mutually exclusive" and
this change maintains that.
Depends on D62067
Differential Revision: https://phabricator.services.mozilla.com/D62130
--HG--
extra : moz-landing-system : lando
The annotation was removed in bug 1613380, but it happens again. Let's
add it back.
Differential Revision: https://phabricator.services.mozilla.com/D62117
--HG--
extra : moz-landing-system : lando
This removes nsStyleImageRequest by moving the load state to LoadData instead
(where other lazy state like the resolved URL and load id lives).
That way we can use cbindgen for more stuff (there's no blocker for using it for
all images now), and we can undo the image tracking shenanigans that I had to do
in bug 1605803 in nsImageFrame.
This removes the mDocGroup member because well, there's no real upside of that
now that quantum DOM is not a thing.
It also removes the static clones of the image requests, and the need for each
computed value instance to have its own request. These were needed because we
needed the image loader for the particular document to observe the image
changes. But we were also tracking the request -> loader for other purposes.
Instead, Now all the images get loaded with GlobalImageObserver as a listener,
which looks in the image map and forwards the notification to all the interested
loaders instead dynamically.
The style value is only responsible to load the image, and no longer tracks /
locks it. Instead, the loader does so, via the image tracker.
Differential Revision: https://phabricator.services.mozilla.com/D58519
--HG--
extra : moz-landing-system : lando
The call to InitializeCanvasRenderer earlier in the function can lose
the context.
Differential Revision: https://phabricator.services.mozilla.com/D62100
--HG--
extra : moz-landing-system : lando
Annotate optiontext.html for Android as slightly fuzzy, to account for
reftest rebucketing fuzzy-failure fallout. It has 0 in the lower bound
of the fuzzy annotation because not every Android has this
fuzzy-failure.
Meanwhile, bug453105.html no longer fails due to reftest rebucketing, so
I remove its fuzzy annotation.
Differential Revision: https://phabricator.services.mozilla.com/D61877
--HG--
extra : moz-landing-system : lando
When structured clone reads a SAB and creates a new SAB object, or
when it serializes a SAB onto a channel, call a callback that lets the
embedder know. The embedder can then adjust its policy. Concretely,
we want to allow the browser to serialize threads in a process that
uses JS shared memory.
Note, for WebAssembly.Memory, reading and writing are delegated to the
cloning operations for SAB, so no special handling is needed.
Differential Revision: https://phabricator.services.mozilla.com/D61455
--HG--
extra : moz-landing-system : lando
When structured clone reads a SAB and creates a new SAB object, or
when it serializes a SAB onto a channel, call a callback that lets the
embedder know. The embedder can then adjust its policy. Concretely,
we want to allow the browser to serialize threads in a process that
uses JS shared memory.
Note, for WebAssembly.Memory, reading and writing are delegated to the
cloning operations for SAB, so no special handling is needed.
Differential Revision: https://phabricator.services.mozilla.com/D61455
--HG--
extra : moz-landing-system : lando
The new verifyStorage() function takes current storage structure on disk and compares it with the expected structure. The expected structure is defined in JSON and consists of a per test package definition and a shared package definition. The shared package definition contains unknown files and directories which need to be ignored in all upgrade methods.
The new infrastructure for checking storage structure will be used later in other tests to verify handling of unknown or obsolete stuff for example during temporary storage initialization.
Differential Revision: https://phabricator.services.mozilla.com/D61450
--HG--
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset cb706e608d58 (bug 1608759)
Backed out changeset f2a08319ac10 (bug 1608759)
--HG--
extra : amend_source : 251fcc6d6304fe6a4ed240f6d1d409fc168f1c31
The new verifyStorage() function takes current storage structure on disk and compares it with the expected structure. The expected structure is defined in JSON and consists of a per test package definition and a shared package definition. The shared package definition contains unknown files and directories which need to be ignored in all upgrade methods.
The new infrastructure for checking storage structure will be used later in other tests to verify handling of unknown or obsolete stuff for example during temporary storage initialization.
Differential Revision: https://phabricator.services.mozilla.com/D61450
--HG--
extra : moz-landing-system : lando
Tests that selecting a contentEditable node with style `user-select:
none` via `execCommand` doesn't trigger an assertion.
Differential Revision: https://phabricator.services.mozilla.com/D61829
--HG--
extra : moz-landing-system : lando
I thought this would fix <input type=number style="user-select: none">, but
turns out it doesn't.
<input type=number> doesn't have the editor root as a root of the anonymous
subtree, so the current hack wouldn't work, as the anon root wouldn't have the
editable flag. So tweak the code a bit to handle stuff in a simpler way than
setting the flags after the fact, and set the NAC-root flag earlier to avoid
the mOuterWrapper->AppendChildTo(root) call forgetting about root's flags.
I had to tweak one AccessibleCaret test, but that's because it uses <textarea>
with user-select: none, and our behavior there is not particularly sane. It just
happened to work because that test-case also had a bunch of contenteditable
elements, and we stop matching this rule:
https://searchfox.org/mozilla-central/rev/220a3bd6063fcbe5ca50e88dcabdc7dee0aca448/layout/style/contenteditable.css#22
Because the anonymous div now properly matches :-moz-read-write, which made the
rule apply and the test work. See comment 4 of this bug.
I'll fix this stuff up and add some tests for our behavior here in bug 1611699.
I refactored the dragdrop tests to cover more input types, but I ended up not
being able to use them because they're dependent on the content.
Instead I added an extra test and changed the refactor so that it applies to
<input type=search>, as there's layout work going on in bug 558594, and it'd be
unfortunate to regress this there too.
Differential Revision: https://phabricator.services.mozilla.com/D61094
--HG--
extra : moz-landing-system : lando
Please review the changes to Errors.msg very carefully. I caught a number of
mistakes there in self-review (e.g. not renumbering replacement markers
correctly when I added {0} to the beginnings of strings), and my confidence
that I caught them all is only middling.
A few lines (MSG_USELESS_SETTIMEOUT, MSG_TYPEDARRAY_IS_DETACHED,
MSG_NOT_SUBMIT_BUTTON) were removed from Errors.msg either because they were
already unused or because they either were single-user constant strings or
became such in the new setup and we could just use the string version of
ThrowTypeError.
Differential Revision: https://phabricator.services.mozilla.com/D61523
--HG--
extra : moz-landing-system : lando
This makes it easier to static_assert correct use. It caught several bugs in
the next patch in this stack.
I had to disambiguate some calls to the templated ThrowDOMException that are
inside the binding_detail namespace, because otherwise they were trying to call
teh non-template function of the same name that's declared in binding_detail.
Differential Revision: https://phabricator.services.mozilla.com/D61522
--HG--
extra : moz-landing-system : lando
This adds the name of the interface and method to the beginning of the exception
string when reporting the exception from Web IDL codegen, so it's clearer what
was called.
Some existing error messages are adjusted to not duplicate the information
about which method was called.
Differential Revision: https://phabricator.services.mozilla.com/D61521
--HG--
extra : moz-landing-system : lando
This removes nsStyleImageRequest by moving the load state to LoadData instead
(where other lazy state like the resolved URL and load id lives).
That way we can use cbindgen for more stuff (there's no blocker for using it for
all images now), and we can undo the image tracking shenanigans that I had to do
in bug 1605803 in nsImageFrame.
This removes the mDocGroup member because well, there's no real upside of that
now that quantum DOM is not a thing.
It also removes the static clones of the image requests, and the need for each
computed value instance to have its own request. These were needed because we
needed the image loader for the particular document to observe the image
changes. But we were also tracking the request -> loader for other purposes.
Instead, Now all the images get loaded with GlobalImageObserver as a listener,
which looks in the image map and forwards the notification to all the interested
loaders instead dynamically.
The style value is only responsible to load the image, and no longer tracks /
locks it. Instead, the loader does so, via the image tracker.
Differential Revision: https://phabricator.services.mozilla.com/D58519
--HG--
extra : moz-landing-system : lando
Behavior changes:
1) We now throw a TypeError, not a SecurityError, when the script URI scheme is
not 'http' or 'https', like the spec says to.
2) We now throw when the scope URI scheme is not 'http' or 'https', like the
spec says to.
3) We now throw a proper TypeError, not a DOMException, at the end of
CheckForSlashEscapedCharsInPath.
4) More informative error messages.
Differential Revision: https://phabricator.services.mozilla.com/D61782
--HG--
extra : moz-landing-system : lando
There are cases where the initial BrowsingContext that we create for a
FrameLoader will never have a DocShell created for it. In the particular case
when the frame it belongs to is part of an inactive document, trying to
eagerly attach the BrowsingContext ends up attaching it as an active child of
its parent BrowsingContext, when it should be either cached or detached. Which
causes no end of problems.
This patch delays attaching the BrowsingContext until the FrameLoader is
initialized, which solves most of these problems.
Differential Revision: https://phabricator.services.mozilla.com/D59009
--HG--
extra : moz-landing-system : lando
There are all sorts of lifecycle issues which arise from making DocShell
responsible for discarding BrowsingContexts. In this particular bug, we tend
to run into them in cases where we create a BrowsingContext for a FrameLoader,
and then never create a DocShell for it, leading to it never being destroyed.
But there are myriad other issues as well.
This patch moves the responsibility for BrowsingContext lifecycle management
to the FrameLoader/FrameLoaderOwner, rather than the DocShell, which makes
things more consistent, and more closely aligns with spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D59008
--HG--
extra : moz-landing-system : lando
Otherwise we're using state from the pre-open document for whatever content is
being written, which is not likely to be right.
Differential Revision: https://phabricator.services.mozilla.com/D61865
--HG--
extra : moz-landing-system : lando