Requiring callers to manually cleanup all DOM references that they create runs
counter to the usual JavaScript model of automatic garbage collection, where
developers usually do not need to think about manual deallocation. It's bound
to lead to leaks before long.
This patch adds a finalization witness bound to the element of any DOM
reference that we create. When that element is destroyed, the finalization
witness also removes its entry from the ID map.
Since the mappings are already stored as weak references, this shouldn't
result in a change to the behavior that callers see, only in the underlying
memory management. It essentially makes this behave as a true weak value map.
Differential Revision: https://phabricator.services.mozilla.com/D35354
--HG--
extra : rebase_source : baab8063668594df452697aae6e2115adfc43ab3
UUIDs are expensive to create, to use as map keys, and to transfer between
processes. They are also completely unnecessary for this use case, since the
number returned by Math.random() has the same characteristics that we're
depending on the UUID generator for, only with better performance.
That said, even Math.random() is probably overkill for this use case, when we
can just use continually incremented serial number and get the same behavior,
but I decided to continue using randomized IDs mainly to minimize the
magnitude of the change.
--HG--
extra : rebase_source : 1536569eca7442f1ae4dcd894cac6a7c39edbb2c
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
The `WebProgressChild` no longer sends a `matchedList` parameter in its JSON
messages to the `RemoteWebProgress`, so it will always be undefined and trigger
a `ReferenceError`.
Differential Revision: https://phabricator.services.mozilla.com/D33202
--HG--
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
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
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
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
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
There have been several people that thought app update was broken because this message was reported as an error so just use logStringMessage
Differential Revision: https://phabricator.services.mozilla.com/D31524
--HG--
extra : moz-landing-system : lando
Expose the driver vendor information (applies to Linux only at this
moment) to crash report telemetry and about:support. This will be useful
when debugging issues to know specifically what driver is in use.
Also expose the monitor information for Linux. Part 1 provides an
implementation to get the monitor information on said platform.
Differential Revision: https://phabricator.services.mozilla.com/D29472
Expose the driver vendor information (applies to Linux only at this
moment) to crash report telemetry and about:support. This will be useful
when debugging issues to know specifically what driver is in use.
Also expose the monitor information for Linux. Part 1 provides an
implementation to get the monitor information on said platform.
Differential Revision: https://phabricator.services.mozilla.com/D29472
Expose the driver vendor information (applies to Linux only at this
moment) to crash report telemetry and about:support. This will be useful
when debugging issues to know specifically what driver is in use.
Also expose the monitor information for Linux. Part 1 provides an
implementation to get the monitor information on said platform.
Differential Revision: https://phabricator.services.mozilla.com/D29472
Make sure we continue to leave JS un-minified for Nightly builds and add a missing FENNEC_NIGHTLY to AppConstants.jsm which got missed in bug 1547710.
Differential Revision: https://phabricator.services.mozilla.com/D29724
--HG--
extra : moz-landing-system : lando
This patch introduces a new type of content process, which has a dynamic name.
This type of content process is labeled as `webIsolated=${SITE_ORIGIN}` and is
used within fission-enabled windows.
To enable this, additional information about the fission status of the target
window must be passed into E10SUtils. This was done by updating every call site
manually to pass an extra boolean. A better solution perhaps should be used in
the future.
With this patch enabled, we now perform process switches, but only when
navigating to HTTP URIs. If we navigate to a non-HTTP URI in an iframe with
fission enabled, it will not behave correctly. This must be done in a
follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29570
--HG--
extra : moz-landing-system : lando
For large header images, built-in memory caching does not work correctly, and
we wind up seeing a flicker any time a new window is opened or becomes active.
This patch caches the header image in an Image element at startup, and uses
that element as the backing for the header image in all browser windows.
Differential Revision: https://phabricator.services.mozilla.com/D29554
--HG--
extra : source : 6159d01c9341088edcabb318259c8ce6201c61ac
extra : amend_source : c43c543fd142f11b8439a6011a6ffe0f610e1015
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
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
Almost none of the prompts that we are currently showing still get dismissed, which messes up our
measurements in this probe. Most of them are persistent now, which means that we should record when
they get removed instead of dismissed to receive meaningful data. This patch does that.
Differential Revision: https://phabricator.services.mozilla.com/D26944
--HG--
extra : moz-landing-system : lando
Includes an otherwise-automated change to test_jsctypes.js that required an
expectation change in test_ctypes.xul.
Differential Revision: https://phabricator.services.mozilla.com/D27449
--HG--
extra : moz-landing-system : lando
Result of running:
$ mach eslint -funix toolkit/ | sed -Ee 's/:.+//' - | xargs sed -E \
-e 's/throw ((["`])[^"]+\2);/throw new Error(\1);/g' \
-e 's/throw ((["`])[^"]+\2 \+ [^ ";]+);/throw new Error(\1);/g' \
-e 's/throw \(/throw new Error(/g' -i
...and then reverting a couple of places where comments were touched,
as well as changes to toolkit/components/ctypes/tests/unit/test_jsctypes.js
that required expectation changes to
toolkit/components/ctypes/tests/chrome/test_ctypes.xul
Differential Revision: https://phabricator.services.mozilla.com/D27448
--HG--
extra : moz-landing-system : lando
Since we rarely touch this code, I took the liberty of changing this to a JS class
and fix the contrast ratio calculations to actually conform to the WCAG spec,
instead of using arbitrary constants.
I changed the `isBright` getter to `useBrightText`, because that is more apt;
we're usually looking for an answer to 'should I use white text on this background?',
instead of looking for an arbitrary threshold to classify a color as being bright.
I updated the tests to cover more of this and clarified the assertion messages as
well.
Differential Revision: https://phabricator.services.mozilla.com/D26097
--HG--
extra : moz-landing-system : lando
We do not need to handle onProgressChange64 notifications since the TabChild's
web progress events are filtered through an nsBrowserStatusFilter, which
truncates onProgresChange64 event values to 32-bit integers and then calls
onProgressChange.
Differential Revision: https://phabricator.services.mozilla.com/D25649
--HG--
extra : moz-landing-system : lando
Now that we have access to the RemoteWebProgress from the TabParent and can
construct RemoteWebProgress and RemoteWebProgressRequests in C++, we can
reconstruct the RemoteWebProgress and RemoteWebProgressRequest in the TabParent
instead of RemoteWebProgressManager. This improves the API for nsIBrowser and
RemoteWebProgressManager, removing the need for the
`callWebProgressContentBlockingEventListeners` method in both. It also means we
won't need to implement `callWebProgress*Listeners` for methods on nsIBrowser
and RemoteWebProgressManager for all other nsIWebProgress events.
Differential Revision: https://phabricator.services.mozilla.com/D24942
--HG--
extra : moz-landing-system : lando
The RemoteWebProgressManager is now implemented in terms of a
nsIWebProgressListener. This paves the way for reconstructing the
nsIWebProgress and nsIRequest passed to the event handlers in C++ instead of in
JS and will alllow for a cleaner overall design.
While here, I also cleaned up RemoteWebProgressManager to use the class
syntactic sugar.
Differential Revision: https://phabricator.services.mozilla.com/D24941
--HG--
extra : moz-landing-system : lando
Abdoulaye O. Ly
Neil Deakin
Kris Maglione
Barret Rennie
Narcis Beleuzu
Brindusan Cristian
Boris Zbarsky
Paul Zuehlcke
Ehsan Akhgari
Gijs Kruitbosch
premk
Dorel Luca
Mihai Alexandru Michis
Ricky Rosario
Mike Conley
Noemi Erli
Mark Banner
Bogdan Tara
Thomas Nguyen
Cosmin Sabou
Henri Sivonen
Edgar Chen
Jonathan Kingston
Tom Ritter
Andrew Osmond
Joel Maher
Tim Nguyen
Michael Kaply
Mike de Boer
Christoph Kerschbaumer
Brendan Dahl
Brad Werth
Robert Strong
Razvan Maries
Shane Caraveo
Coroiu Cristina
Ciure Andrei
Andreea Pavel
Daniel Varga
Ryan VanderMeulen
Nika Layzell
Myk Melez
Geoff Lankow
Gurzau Raul
Magnus Melin
Jan-Erik Rediger
Andrea Marchesini
Andrew Swan
Ryan Hunt
Robert Helmer
Johann Hofmann
Rob Wu
Ian Moody
Brian Grinstead
Felipe Gomes
meandave