This patch does not make some header files stop including the inline
header because fixing them require more changes.
Note that `#include "nsComponentManagerUtils.h"` is fixing a bustage
caused by "use of undeclared identifier 'do_CreateInstance'" error.
Differential Revision: https://phabricator.services.mozilla.com/D304432
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
The issue occurs when a JavaScript URI is being loaded while image loads are also
triggered at the same time. If images finish loading before the Javascript URI
completes execution, e.g. requested images are avaiable in image cache or a
synchronous XHR is spining the event loop, the load event might be fired unexpectedly.
This is primarily because the Javascript URI loading is tracked as a state in DocLoader
whenever a Javascript URI load is triggered even if the load event should not fired.
So when image load complete, DocLoader erroneously determines to fire load event
due to document is in Javascript URI loading state.
Differential Revision: https://phabricator.services.mozilla.com/D260780
Prior to this change, all web progress events fired by nsDocLoader
were bubbled to the toplevel in-process nsDocShell instance, then
captured by web progress listener. This listener would filter the
notifications (using nsBrowserStatusFilter), then send them either
directly to the BrowsingContextWebProgress, or via. PBrowser to the
BrowsingContextWebProgress.
Unfortunately, these events are modified as they are bubbled (e.g.
changing the progress flags to remove STATE_IS_NETWORK), which combined
with the filtering from nsBrowserStatusFilter led to some strange
behaviour in the notifications.
This change skips the in-content bubbling by directly propagating events
from the nsDocShell they were fired on to the corresponding
BrowsingContextWebProgress, and then performing the bubbling within the
parent process.
The one major exception to this is OnProgressChange, which relies on
nsDocLoader's handling on aCurTotalProgress and aMaxTotalProgress.
Because of that, these listeners continue to capture progress
notifications exclusively on the toplevel BrowsingContext, and do not
handle out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D249651
Prior to this change, all web progress events fired by nsDocLoader
were bubbled to the toplevel in-process nsDocShell instance, then
captured by web progress listener. This listener would filter the
notifications (using nsBrowserStatusFilter), then send them either
directly to the BrowsingContextWebProgress, or via. PBrowser to the
BrowsingContextWebProgress.
Unfortunately, these events are modified as they are bubbled (e.g.
changing the progress flags to remove STATE_IS_NETWORK), which combined
with the filtering from nsBrowserStatusFilter led to some strange
behaviour in the notifications.
This change skips the in-content bubbling by directly propagating events
from the nsDocShell they were fired on to the corresponding
BrowsingContextWebProgress, and then performing the bubbling within the
parent process.
The one major exception to this is OnProgressChange, which relies on
nsDocLoader's handling on aCurTotalProgress and aMaxTotalProgress.
Because of that, these listeners continue to capture progress
notifications exclusively on the toplevel BrowsingContext, and do not
handle out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D249651
This is somewhat complex, untested, never shipped, and predates
fission.
Remove it to simplify the code.
Depends on D198183
Differential Revision: https://phabricator.services.mozilla.com/D198184
Previously it may have been possible in some edge cases for us to send
`MaybeFireEmbedderLoadEvents` for a non-toplevel frame during docshell
tree teardown.
Differential Revision: https://phabricator.services.mozilla.com/D197825
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
Masayuki Nakano