CLOSED TREE
Backed out changeset d3d67293f115 (bug 1623413)
Backed out changeset 75ed1b8a5c67 (bug 1623413)
Backed out changeset 0eef32d6a454 (bug 1623413)
Though there is no automated test for this change, I think the test cases in the
previous commit well cover the original issue (bug 468568) that downloadable
fonts are not rendered in printing.
Depends on D89095
Differential Revision: https://phabricator.services.mozilla.com/D89096
Canvas only has one context, and that assumption is pretty baked into
the code, so having an API that pretends otherwise is silly.
Differential Revision: https://phabricator.services.mozilla.com/D88990
I had written this on one of my attempts to fix the missing text on
reddit when printing, but I think it's worth landing anyways not only
because it's slightly cleaner, but because it avoids the virtual call
and style checks when we're not printing.
This should be an idempotent change.
Differential Revision: https://phabricator.services.mozilla.com/D89171
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
This ensures that we call the callback again if the canvas becomes
displayed later. This is important because a callback may run after
destroying the frame tree, and in that case some canvas operations may
fail. Without this there's no guarantee that the callback runs ever
again.
Depends on D89111
Differential Revision: https://phabricator.services.mozilla.com/D89112
We still reframe for additions / removals of the attribute because that
makes us create the placeholder <div>. We could avoid it if we created
it independently of the presence of the attribute but that seems like it
could regress perf for the case where there's no placeholder attribute,
which is probably common enough.
Differential Revision: https://phabricator.services.mozilla.com/D88724
We set pending visual scroll updates even for RSFs that are on subdocuments,
so we should ensure they get acknowledged and cleared on paints. Otherwise
the pending visual scroll update can get "stuck" and it affects things that
depend on it, such as the drag-selection code.
Differential Revision: https://phabricator.services.mozilla.com/D88893
We set pending visual scroll updates even for RSFs that are on subdocuments,
so we should ensure they get acknowledged and cleared on paints. Otherwise
the pending visual scroll update can get "stuck" and it affects things that
depend on it, such as the drag-selection code.
Differential Revision: https://phabricator.services.mozilla.com/D88893
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
During scrolling, the caret's position relative to the
custom-content-container (cached in mImaginaryCaretRectInContainerFrame)
may not change, but its position relative to root frame can (cached in
mImaginaryCaretRect).
We need to update mImaginaryCaret each time we are in SetPosition().
Otherwise, the caret still remembers its pre-scrolling old position next
time when we drag it, resulting the caret jumping to its old
pre-scrolling position suddenly.
Note this bug only occurs on the root scroll frame where the APZ is
enabled, not in any sub-scroll frames where APZ is disable when the
caret is shown.
Differential Revision: https://phabricator.services.mozilla.com/D88638
We still reframe for additions / removals of the attribute because that
makes us create the placeholder <div>. We could avoid it if we created
it independently of the presence of the attribute but that seems like it
could regress perf for the case where there's no placeholder attribute,
which is probably common enough.
Differential Revision: https://phabricator.services.mozilla.com/D88724
We already use SetProperty() extensively for nsFrameList properties like
OutsideMarkerProperty(), BackdropProperty(), etc, so we can simplify the
interface by removing SetPropTableFrames().
Differential Revision: https://phabricator.services.mozilla.com/D88459
Because the frame property look-up is expensive, change the
SetOverflowFrames(), SetOverflowContainers(), and
SetExcessOverflowContainers() to return the frame list so that the
caller don't need to use Get methods to retrieve it again.
Differential Revision: https://phabricator.services.mozilla.com/D88458
Not all APIs added in this patch are used immediately, but for the sake of
completeness, they are all added.
Their document will be updated in Part 3 after adding the relevant APIs for
ExcessOverflowContainersProperty().
nsContainerFrame::DrainExcessOverflowContainersList() has several calls to set
OverflowContainersProperty() whose life cycle need special attention. We will
deal with them later in Part 4.
Differential Revision: https://phabricator.services.mozilla.com/D88456
It's useful to use `std::move()` to indicate the frames' ownership in one list
is transferred to the another list.
For a frame list managed by AutoFrameListPtr, after moving its frames to
another list, it can be automatically deleted when it is going out of
scope.
Differential Revision: https://phabricator.services.mozilla.com/D88455
I feel skipIncremental is hard to reasoning. It's easier to list all the
possible reasons that the child needs to be reflowed again.
Differential Revision: https://phabricator.services.mozilla.com/D88699
Rename so that its naming is consistent with ReflowConfig::mColISize,
and to avoid confusion with ColumnBalanceData::mMaxBSize.
Differential Revision: https://phabricator.services.mozilla.com/D88697
There are cases where the code rebuilds the ScrollMetadata for a scrollframe
multiple times. This violates implicit assumptions in the NotifyApzTransaction
code that it will only be called after the ScrollMetadata is built for a particular
transaction. This patch moves the NotifyApzTransaction call to the end of the
metadata-building phase so that those assumptions are upheld.
Differential Revision: https://phabricator.services.mozilla.com/D88650
eTopLevel is reused in content process to indicates that the mouse leaves
the puppet widget rendering area, now we add a separated type, ePuppet, for it.
Differential Revision: https://phabricator.services.mozilla.com/D84748
For now, we *only* use this new page-skipping code during print preview, via a
PresContext::IsScreen() check. There's a separate legacy codepath that we'll
continue to use for skipping pages during actual printing; see e.g.
nsPageSequenceFrame::DetermineWhetherToPrintPage(). I intend to replace that
codepath soon, but for now I'm leaving it intact, in the interests of making
this patch minimally invasive & low-risk for beta uplift.
Differential Revision: https://phabricator.services.mozilla.com/D87394
This patch shouldn't change behavior at all.
Since our print reflow pipeline doesn't try to handle incremental reflow (per
the early return in nsPageSequenceFrame::Reflow), we can safely assume that our
page frames don't have a preexisting next-in-flow (until we explicitly create
one for them).
This simplifies the logic & the number of scenarios that we need to consider.
Differential Revision: https://phabricator.services.mozilla.com/D88470
This patch shouldn't change behavior.
After this change, we'll be able to reason about the page range during reflow
(in a later patch in this series). The old place where we determine the
page-range information -- in nsPageSequenceFrame::StartPrint -- unfortunately
runs *after* reflow. So that was running too late for the information to be
useful when we're laying out pages on sheets.
Differential Revision: https://phabricator.services.mozilla.com/D88469
This patch shouldn't change behavior at all; it's just moving some member
variables to a new home on a helper-struct (and the struct's lifetime is the
same as the lifetime of the nsPageSequenceFrame where these member variables
lived, prior to this patch).
These members need to move so that PrintedSheetFrame can have access to them.
PrintedSheetFrame is now where pages are generated, and it will handle our
page-range-induced page skipping, as of a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D88468
This should not have any functional effects, but it maintains a useful invariant
that the stored field is never NotSpecified. NotSpecified should only be used
as a default value for function parameters, and converted to some other origin
when "at rest" in the field.
Differential Revision: https://phabricator.services.mozilla.com/D88665
For all the other scroll-behavior-* tests, the "complex" behaviour is the "test"
and the "let's scroll these things to their intended destination" behaviour is
the "ref", as one would expect. Except for some reason in scroll-behavior-6, the
"ref" branch is the one doing all the tricky scrolling things and the other
branch has the simple intended outcomes. This patch inverts the branches so
that the test behaves more as expected.
Differential Revision: https://phabricator.services.mozilla.com/D88648
Instead of creating an element, flushing styles and getting the computed
value back just to receive, use the existing InspectorUtils.colorToRGBA.
With some refactoring, we can completely get rid of parsing rgba strings
in LightWeightThemeConsumer too, as a benefit. This should be much
faster.
This patch tweaks the InspectorUtils API to allow taking a document, so
that system colors keep working. We could probably get away without
supporting system colors, but it'd technically be a regression, and
since we want this patch to be uplifted, and it's easy, let's avoid
breaking changes.
Differential Revision: https://phabricator.services.mozilla.com/D88200
eTopLevel is reused in content process to indicates that the mouse leaves
the puppet widget rendering area, now we add a separated type, ePuppet, for it.
Differential Revision: https://phabricator.services.mozilla.com/D84748
Instead of creating an element, flushing styles and getting the computed
value back just to receive, use the existing InspectorUtils.colorToRGBA.
With some refactoring, we can completely get rid of parsing rgba strings
in LightWeightThemeConsumer too, as a benefit. This should be much
faster.
This patch tweaks the InspectorUtils API to allow taking a document, so
that system colors keep working. We could probably get away without
supporting system colors, but it'd technically be a regression, and
since we want this patch to be uplifted, and it's easy, let's avoid
breaking changes.
Differential Revision: https://phabricator.services.mozilla.com/D88200
Previously, IsFocusable returned true on elements in print preview documents, but the element wouldn't accept focus.
This meant that when you tried to tab, focus would get stuck on the document.
Now, IsFocusable returns false.
Thus, tab doesn't try to stop on these elements and can move out of the document.
Differential Revision: https://phabricator.services.mozilla.com/D88000
Previously, IsFocusable returned true on elements in print preview documents, but the element wouldn't accept focus.
This meant that when you tried to tab, focus would get stuck on the document.
Now, IsFocusable returns false.
Thus, tab doesn't try to stop on these elements and can move out of the document.
Differential Revision: https://phabricator.services.mozilla.com/D88000
This introduces a linear interpolation when computing the wheel animation
durations, based on the migration percentage of the user. Initially the
migration percentage defaults to 100 (fully migrated) for new users and for
existing users who have customized these prefs. The migration percentage
defaults to zero for existing users without customizations, so they will
still get the old default values of min=200,max=400. Over time we can adjust
the migration pref clamping to move that percentage up and migrate those
users to get the new values.
Differential Revision: https://phabricator.services.mozilla.com/D88163
The editor modules does QI too many times when it sets or removes some style
with `execCommand` or XPCOM API. Therefore, there should be an API to
retrieve `nsStyledElement` pointer from `nsINode*`.
Differential Revision: https://phabricator.services.mozilla.com/D87990
Previously, IsFocusable returned true on elements in print preview documents, but the element wouldn't accept focus.
This meant that when you tried to tab, focus would get stuck on the document.
Now, IsFocusable returns false.
Thus, tab doesn't try to stop on these elements and can move out of the document.
Differential Revision: https://phabricator.services.mozilla.com/D88000
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
SVGSVGElement::SetCurrentScaleTranslate checks that things have changed but if we
manage to update both translate values before we get here then we'll skip the screen update
that we need.
Also
- introduces a tear off for SVGSVGElement.currentTranslate so we hand out the same object as required by the SVG idl
- removes SVGSVGElement::SetCurrentTranslate as dead code
- removes mPreviousScale and mPreviousTranslate from SVGSVGElement as they are no longer necessary
Differential Revision: https://phabricator.services.mozilla.com/D84796
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
The first patch in this bug makes this test a bit more heavy-weight.
Instead of rendering the print-preview document in an iframe, and
snapshotting the 400x400 pixels in the top left corner, we open a window
and snapshot the whole print preview document.
I could keep it doing the same if needed by passing the docshell
argument to window.printPreview. But this test wasn't great to begin
with, and the changes in part 1 are a net improvement imo.
The bad part is that they cause the test to become slower such as it can
time out in some debug builds. Request a longer timeout because of this.
Differential Revision: https://phabricator.services.mozilla.com/D87966
Now that main thread scroll updates preserve the relative scroll offset
in APZ, this hacky fix is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D87687
This retrieves the same settings from the printer as
InitPrintSettingsFromPrinter.
There is probably a lot of scope for de-duplication of code here, but I decided
to try and protect the old fallback paths.
Depends on D87125
Differential Revision: https://phabricator.services.mozilla.com/D87604
This improves the paper assertions to check for attribute type, rather
than checking if the attribute is null, since undefined is not null and
can cause false positives.
Also updates the formatting to be congruent with other related tests.
Differential Revision: https://phabricator.services.mozilla.com/D87783
Before this patch stack, nsPageSequenceFrame and every nsPageFrame each
individually tracked the number of pages.
As of the previous patch, we've coalesced the nsPageFrame variables into a
single variable that lives on nsSharedPageData. This patch here replaces
nsPageSequenceFrame's member-var with that nsSharedPageData variable, too.
Depends on D87696
Differential Revision: https://phabricator.services.mozilla.com/D87697
We already do this static_cast'ing before this patch, for a single
nsPageFrame-specific method call. This patch just captures the result of that
static_cast in a reusable variable, so that I can easily add another
nsPageFrame-specific function call in the next patch of this patch series.
(We can be confident this casting is valid, because we only ever give
PrintedSheetFrame this one type of child frame.)
Differential Revision: https://phabricator.services.mozilla.com/D87695
This patch adds a createDefaultSettings() method to nsIPrinter to
initialize a default print settings object specific to that printer.
It implements the functionality for Linux and macOS but adds only stubs
for Windows.
Differential Revision: https://phabricator.services.mozilla.com/D87125
We do the flex algorithm by assuming the available block-size is
unconstrained. Thus, we can remove `availableBSizeForContent` and
`aStatus` passing to DoFlexLayout(), ComputeMainSize(), and
ComputeCrossSize().
Differential Revision: https://phabricator.services.mozilla.com/D87109
Although this goes against the suggestion of the sample algorithm in the
spec, this brings the layout of the multi-line column-oriented flex
container in paginated context closer to the layout with no
fragmentation. This also matches Google Chrome's behavior.
Tweak flexbox-unbreakable-child-2.html so that it matches the rendering
as of this patch. Change the height of `.muticol` and the removal of
border in `flexContainer` to let two flex items fit exactly into the
flex container's height, making reference easier to write.
Differential Revision: https://phabricator.services.mozilla.com/D87107
This patch adds a createDefaultSettings() method to nsIPrinter to
initialize a default print settings object specific to that printer.
It implements the functionality for Linux and macOS but adds only stubs
for Windows.
Differential Revision: https://phabricator.services.mozilla.com/D87125
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