We don't stop other animations and such, so seems weird to do it only
for animated images. This line comes from bug 70030, but we no longer
provide "Esc" as a shortcut for Stop(), so it's probably no longer
relevant for users.
Differential Revision: https://phabricator.services.mozilla.com/D125815
Even if the old one isn't, otherwise we can leak.
This doesn't happen at the moment because our printing code creates its
own browser with the initial about:blank loaded (which not Destroy()ing
is fine), and then host the clone in there.
In bug 1666247, for simplify mode the front-end is creating a non-static
document with the simplify mode, then reusing the same docshell for the
static document. That means that we forget the non-static document and
we can leak.
In comment 16 on that bug, the leak comes from a <link rel=stylesheet>
whose SheetLoadData we keep in Document::mPreloadService (which uses
Document::Destroy() to call ClearAllPreloads() and break cycles).
To fix it, check aDocument->IsStaticDocument(), not just
mDocument->IsStaticDocument()... That's the right check since it is the
cloning codepath the one that otherwise doesn't care about what was in
the viewer before.
Differential Revision: https://phabricator.services.mozilla.com/D118809
Even if the old one isn't, otherwise we can leak.
This doesn't happen at the moment because our printing code creates its
own browser with the initial about:blank loaded (which not Destroy()ing
is fine), and then host the clone in there.
In bug 1666247, for simplify mode the front-end is creating a non-static
document with the simplify mode, then reusing the same docshell for the
static document. That means that we forget the non-static document and
we can leak.
In comment 16 on that bug, the leak comes from a <link rel=stylesheet>
whose SheetLoadData we keep in Document::mPreloadService (which uses
Document::Destroy() to call ClearAllPreloads() and break cycles).
To fix it, check aDocument->IsStaticDocument(), not just
mDocument->IsStaticDocument()... That's the right check since it is the
cloning codepath the one that otherwise doesn't care about what was in
the viewer before.
Differential Revision: https://phabricator.services.mozilla.com/D118809
These APIs are entirely unused (aside from one usage in a test, which part 1 in
this patch series removed), so this patch shouldn't impact behavior at all.
Historical note: we briefly removed these APIs once before, in this commit:
https://hg.mozilla.org/mozilla-central/rev/c216ff19d690
...but we brought them back because we had a motivating use case at the time.
We don't have any such motivating use cases any more, though. So, this patch
here is essentially a modernized version of that older commit.
Differential Revision: https://phabricator.services.mozilla.com/D108148
Also, make sure that BFCachePreventionObserver does not fire events for
elements that are part of an anonymous native tree.
Differential Revision: https://phabricator.services.mozilla.com/D103812
We keep mMedium in nsPresContext rather than just looking it up in the
browsing context because that's used quite more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D103782
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
This was only being checked on OnDonePrinting() which isn't called in
the original docshell. Move it to the window because we don't need to
care about document viewers getting closed during print operations,
they're top level browsers that don't run script.
Differential Revision: https://phabricator.services.mozilla.com/D91416
