The requestor should be ourselves: the toplevel docshell that the tabgroup does
not need to look in when doing the search.
Differential Revision: https://phabricator.services.mozilla.com/D32422
--HG--
extra : moz-landing-system : lando
To extract Huffman tables (see bug 1552435), we need the ability to walk through the grammar.
This patch starts implementing grammar walking, as macros - at this stage, sufficiently to walk
through interfaces and start dealing with their fields.
Depends on D32291
Differential Revision: https://phabricator.services.mozilla.com/D32295
--HG--
extra : moz-landing-system : lando
Changes:
- enabled SM(p) runs on `windows10-aarch64` for `built-projects`
- turn off `jittest` runs for all platforms matching `android-hw-.*-aarch64/.*`
Differential Revision: https://phabricator.services.mozilla.com/D32220
--HG--
extra : moz-landing-system : lando
The official layout had this same problem, so this just causes the mechanism
that was added to solve it there to also be invoked for every other branding.
Differential Revision: https://phabricator.services.mozilla.com/D32504
--HG--
extra : moz-landing-system : lando
When TV runs the reftest harness against an individual reftest, and the specified reftest
is in a sub-directory of its manifest location, the harness currently fails to run the
requested test, on Windows only. For example, the pathname in findManifest might be
"css-multicol\multicol-nested-002.xht", on Windows. Using posixpath changes pathname to
"css-multicol/multicol-nested-002.xht", regardless of platform, and that seems to work
everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D32361
--HG--
extra : moz-landing-system : lando
I was clearly trying to do that in bug 882653 part 3 and failed to. Our
current behavior of passing two args to this error message (which only takes
one arg) is silly, and the only thing that makes it at all sane is that we only
use it in class hooks, which can never have the wrong sort of object, so it's
unreached code.
The comment cleanup is just to make the role of CGAbstractBindingMethod. and
the validity of the changes to it, clearer.
Differential Revision: https://phabricator.services.mozilla.com/D32478
--HG--
extra : moz-landing-system : lando
There are two related problems this patch is trying to address. The first, and
simpler, one is bug 1553436: there are websites that use existing variables and
functions named "u2f" and adding a non-replaceable readonly property with that
name on Window breaks them. The fix for this is straightforward: mark the
property [Replaceable].
The second problem, covered by bug 1551282, involves sites that use the Google
U2F polyfill. The relevant parts of that polyfill look like this:
'use strict';
var u2f = u2f || {};
u2f.register = some_function_that_only_works_right_in_Chrome;
u2f.sign = some_function_that_only_works_right_in_Chrome;
The failure mode for that code before this fix is that the assignment to "u2f"
throws because it's a readonly property and we're in strict mode, so any code
the page concatenates in the same file after the polyfill does not get run.
That's what bug 1551282 is about. The [Replaceable] annotation fixes that
issue, because now the polyfill gets the value of window.u2f and then redefines
the property (via the [Replaceable] setter) to be a value property with that
value. So far, so good.
But then we need to prevent the sets of u2f.register
and u2f.sign from taking effect, because if they are allowed to happen, the
actual sign/register functionality on the page will not work in Firefox. We
can't just make the properties readonly, because then the sets will throw due
to being in strict mode, and we still have bug 1551282. The proposed fix is to
make these accessor properties with a no-op setter, which is exactly what
[LenientSetter] gives us.
The rest of the patch is just setting up infrastructure for generating the
normal bits we would generate if "sign" and "register" were methods and using
that to create the JSFunctions at the point when the getter is called. The
JSFunctions then get cached on the u2f instance object.
Differential Revision: https://phabricator.services.mozilla.com/D32357
--HG--
extra : moz-landing-system : lando
The CustomizableUI does not delete the _addedEventListeners property from
the view node when the widget is destroyed. This stops the widget from
correctly having events dispatched to it after recreating it, as the
initialization code assumes that it has already been set up.
Differential Revision: https://phabricator.services.mozilla.com/D31677
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
The BrowserParent's IPC receive methods for nsIWebProgress events in the
BrowserChild were all doing the same set up to ensure they had the correct
state to process them. This has now been refactored out into a single method.
Differential Revision: https://phabricator.services.mozilla.com/D30730
--HG--
extra : moz-landing-system : lando
Before the WebProgress event handlers started migrating to C++, the parent
process would only receive WebProgress events after the child process had
finished loading the WebProgressChild script. Now that listeners are registered
much earlier (before the BrowserChild has finished setting up its frame
scripts), the BrowserParent would receive WebProgress events that were
heretofore not received unless the BrowserChild was *very* careful about when
it sent the IPC messages.
However, even while being very careful, the OnStateChange event handler would
always fire events for initial about:blank loads that break a lot of unit
tests. Before porting that event, we are now ensuring that the WebProgressChild
has finished loading before the BrowserChild will send IPC messages for these
events to the BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D30252
--HG--
extra : moz-landing-system : lando
The idea is that we should only generate concreate-binding (wrap methods, etc)
machinery for an interface by default if we have reason to expect that the
interface is used as the primary interface for some objects. Two clear signals
that would indicate that are the interface being a leaf interface (with no
descendants) and the interface having a constructor. Other cases would require
a 'concrete' annotation in Bindings.conf.
Differential Revision: https://phabricator.services.mozilla.com/D32208
--HG--
extra : moz-landing-system : lando
This should keep people from marking things concrete unnecessarily just so
their example-generated WrapObject works.
Differential Revision: https://phabricator.services.mozilla.com/D32207
--HG--
extra : moz-landing-system : lando
It's dead code because we never create MIDIPort objects directly,
and all subclasses override WrapObject.
Differential Revision: https://phabricator.services.mozilla.com/D32206
--HG--
extra : moz-landing-system : lando
It's dead code because we never create AuthenticatorResponse objects directly,
and all subclasses override WrapObject.
Differential Revision: https://phabricator.services.mozilla.com/D32205
--HG--
extra : moz-landing-system : lando
It's dead code, because ReportBody is an abstract class and subclasses override
WrapObject.
Differential Revision: https://phabricator.services.mozilla.com/D32204
--HG--
extra : moz-landing-system : lando
It's dead code, because we never create PerformanceEntry objects directly and
subclasses override WrapObject.
Differential Revision: https://phabricator.services.mozilla.com/D32203
--HG--
extra : moz-landing-system : lando
It's dead code, because AudioScheduledSourceNode is an abstract class and all
subclasses override WrapObject.
Differential Revision: https://phabricator.services.mozilla.com/D32202
--HG--
extra : moz-landing-system : lando
