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
This broke in bug 1636728 because we started setting the bit in the
cloned docshell rather than the original one.
Behavior in other browsers seems to be a bit all over the place, but for
now keeping our behavior during window.print() seems sane.
Differential Revision: https://phabricator.services.mozilla.com/D90456
ChildSHistory.legacySHistory isn't valid for content processes when
session history in the parent is enabled. We try to fix this by either
delegating to the parent by IPC or move the implementation partially
or as a whole to the parent.
Differential Revision: https://phabricator.services.mozilla.com/D89353
This shouldn't generally happen, but seems it can under some circumstances and
even though I've fixed the error condition that triggers this a null-check here is harmless.
Differential Revision: https://phabricator.services.mozilla.com/D89453
Before bug 1636728 this couldn't happen because print documents weren't
hosted in an <browser>. The presentation of documents that are being
printed should be managed by the print job.
We should, in fact, probably just make mDocument->IsStaticDocument() the
condition, or such.
Differential Revision: https://phabricator.services.mozilla.com/D88901
Other engines also do this, but with my previous patch breaks it
(because we only hit print() on the print-content-viewer _after_ doing
the clone).
So move it before triggering all the machinery, and only for
window.print(). Given we didn't check this for print preview etc, I
think it's fine to carry on for user-triggered loads.
Trivial test-case (which I'm not quite sure how to turn into an
automated test...)
<!doctype html>
<h1>I do get printed but...</h1>
<script>
window.print();
</script>
<h2>Do I?</h2>
Note that this is broken with the new print preview UI already, this
fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D87898
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
This is backed by an existing nsPageSequenceFrame API, which this patch also
renames to use the word "Raw" for consistency across the full callstack.
Differential Revision: https://phabricator.services.mozilla.com/D87886
This change consists of;
1) Use switch statement for the given PrintPreview Navigation type.
2) Simply iterate over the children of nsPageSequenceFrame for
PRINTPREVIEW_GOTO_PAGENUM
3) Use GetCurrentSheetFrameAndPageNumber for PRINTPREVIEW_PREV_PAGE and
PRINTPREVIEW_NEXT_PAGE so that it should now match
printPreviewCurrentPageNumber
(that means the edge case where the current scroll position is in
the gap between pages has been fixed by this change)
4) Scroll to the position where the target frame is positioned at the center of
the print preview scroll port in the cases of PRINTPREVIEW_PREV_PAGE,
PRINTPREVIEW_NEXT_PAGE and PRINTPREVIEW_GOTO_PAGENUM
4) is a bit debatable but it can be now easily modified by changing
ComputeScrollPositionFrameAtCenter later if it turns out the current way is not
reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D87548
So that we can keep using the logic in the old print preview UI.
For the new print preview UI, the original PrintPreviewScrollToPage will be
modified gradually in subsequent changes.
Differential Revision: https://phabricator.services.mozilla.com/D87543
Unfortunately there is no particular way to write automated tests without
exposing a bunch of metrics in the print preview window, such as each
PrintedSheetFrame height, the gap length between the sheets, print preview
scale, the scroll port rect, the current scroll position, etc. etc. So I just
tested this change with the frontend change to show the current page number
there by :mstriemer. [1]
[1] https://phabricator.services.mozilla.com/D86427
Differential Revision: https://phabricator.services.mozilla.com/D87203
This code was there to prevent stuff like bug 424377, but nowadays clone
documents are data documents to begin with, so they can't load scripts.
Differential Revision: https://phabricator.services.mozilla.com/D86948
