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
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
Specifically:
- Remove hit test tag from common display item properties.
- Simplify WR bindings to use hit-test items exclusively.
- Remove support for transparent rectangles to be hit-test items.
- Remove support for any primitive to be a hit-test item.
Differential Revision: https://phabricator.services.mozilla.com/D87421
They're enabled in all configurations and there's no plan to change
this. With it, dom.experimental_forms is also useless, so we can remove
it too.
Differential Revision: https://phabricator.services.mozilla.com/D87623
Android-components listens to the GeckoView callback onFirstContentfulPaint to
track whether a contentful paint has occured, in order to decide when to
thumbnail a tab. Currently this gets fired once per tab.
However, when the GeckoSession is paused, we clear cached resources in the
compositor. This means that when the session is resumed, the compositor does not
have the necessary information to render the page (such as painted content
buffers, or the webrender display list). Because android-components attempts to
capture a new thumbnail immediately upon resuming, it ends up capturing a blank
thumbnail.
To fix this, add a new callback onPaintStatusReset() which is invoked when the
cached resources are cleared. Android-components can listen for this to be
informed when the contentful paint is no longer visible. It can then wait until
the subsequent contentful paint occurs before capturing the thumbnail.
Differential Revision: https://phabricator.services.mozilla.com/D87341
By moving the few things that need to be exposed to other components
to APZPublicUtils.h, APZUtils.h becomes much less widely included
(and thus changing it triggers a quicker recompile) while retaining
most of its utilities.
Differential Revision: https://phabricator.services.mozilla.com/D87404
Likewise for RepaintRequest, and direct usages of mScrollOffset
inside FrameMetrics.
The general idea is:
* APZ's copy of the FrameMetrics stores the visual scroll offset,
so calls to GetScrollOffset() on it are replaced with
GetVisualScrollOffset()
* The layer tree's copy of the frame metrics (and copies derived
from that like mLastContentPaintMetrics) currently stores the
layout scroll offset, so calls to GetScrollOffset() on those
are replaced with GetLayoutScrollOffset().
The latter changes are particularly important, as they enable us
to modify the layer tree's copy to store (a main thread snapshot
of) the visual offset in mScrollOffset in a future patch.
This patch intends no functional changes. In the cases where we
change GetScrollOffset() to GetLayoutScrollOffset(), mScrollOffset
and mLayoutViewport.TopLeft() should already be storing the same
thing.
The patch identifies a few usages as suspicious but leaves them
functionally unchanged for now.
A few problematic usages of GetScrollOffset() remain, which will
require other fixes to remove.
Differential Revision: https://phabricator.services.mozilla.com/D87159
By passing a weak reference back to the DocumentChannelParent into
DocumentLoadListener for object loads, we are able to handle process switching
loads by asking the content process to create a BrowsingContext, and delaying
the real process switch until it becomes available.
The load then completes as it would before, acting as a normal process-switching
subframe load.
Differential Revision: https://phabricator.services.mozilla.com/D86580
Note: Previously we were scaling based on the available ISize (and we were
ignoring the BSize for scaling purposes). Now we want to consider the BSize as
well, so the obvious next step would be to scale based on the available BSize -
but that doesn't work, because the available BSize is unconstrained here. (It's
unconstrained, even though we're fragmenting, because thankfully we don't
attempt to fragment the nsPageSequenceFrame itself -- we only fragment at a
level further down in the frame tree.)
So: this patch changes us to instead scale down based on the *computed* size
(rather than the available size), such that both dimensions fit. The computed
size here is the size of the scrollport; and, importantly, it has a finite
value in the block axis (unlike the *available* BSize which is unconstrained
here).
Note that the available ISize and the computed ISize are the same in this case
(they're both the ISize of the scrollport), so there's no behavior-change here
for the computation of the inline-axis-based scale factor.
Differential Revision: https://phabricator.services.mozilla.com/D87021
This hange ensures that the upper-left corner of this test's print-preview
area continues to show the previewed sheet (rather than the uninteresting gray
print preview background color).
Without this test change, the next patch in this series would cause this test's
print-previewed-sheet to be scaled down vertically (and shifted over
horizontally); and the shift is sizeable enough to push the sheet "out of
frame" of the relatively-small area that this test snapshots when doing
screenshot comparisons. We obviously don't want that to happen; that would
nerf this test's screenshot-equality comparisons, and it would also cause this
test's screenshot-not-equal comparisons to start failing.
As noted in the included code-comment in the test: we can probably revert this
change once we've fixed this test to make it compare a larger area of the
print-preview rendering, in bug 1602410.
Differential Revision: https://phabricator.services.mozilla.com/D87317
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
When <object> targets to a svg image, we use nsSubDocumentFrame. The
intrinsic ratio should be overridden by aspect-ratio while computing
its size on this frame.
This update in nsSubDocumentFrame also works in iframe.
Differential Revision: https://phabricator.services.mozilla.com/D79362
This includes a update of the ini file. I noticed the color
of the video is not equal to "rgb(0, 128, 0)" (i.e. background-color: green).
It is "rgb(1, 128. 1)" on Mac (without WebRender),
"rgb(0, 125, 0)" on Mac (with WebRender), and "rgb(1, 128, 2)" on Linux.
Perhaps it is a bug of our video rendering or video scaling. Therefore,
I added fuzzy into the ini file with max 0-3 difference per channel.
(Note: The size of this video is 50x50, so the max number of pixels is 2500.)
Differential Revision: https://phabricator.services.mozilla.com/D79337
In order to apply Automatic content-based minimum sizes, we have to know
the content size on the block axis. We cannot get the content size until
we finish the reflow of the child frames. So we have to keep a flag
which indicates the size of the ratio-dependent axis is overrideen by
aspect-ratio in ReflowInput.
We will set the correct return value in the next patch, For now, we
always return AspectRatioUsage::None.
Differential Revision: https://phabricator.services.mozilla.com/D79335
We calculate the size of ratio-dependent axis by aspect-ratio while
initializing its ReflowInput, for most of the basic block cases.
This patch doesn't include "Automatic content-based minimum sizes",
which will be handled later. Besides, replaced elements will be handled
later as well.
We don't pass abspos-004.tentative.html because there is still a
spec issue: https://github.com/w3c/csswg-drafts/issues/5151.
For other tests we didn't pass (e.g. block-aspect-ratio-009.tentative.html,
or replaced-element-00x.tentative.html), we fix them later.
Besides, in this patch, we don't handle the case if the size of
ratio-determining axis uses intrinsic size keywords (which needs to be
calculated by its content size). We will fix this in the following bug
(Bug 1646100).
Differential Revision: https://phabricator.services.mozilla.com/D78964
Add -moz-inert and -moz-script-level to the set of internal properties
that aren't included in "all".
-moz-inert may need to be uncacheable in the future if we make it not
change the pointer-events computed value. Left a comment to that effect.
Differential Revision: https://phabricator.services.mozilla.com/D87115
This effectively reverts Bug 1441279 Part 6.
https://hg.mozilla.org/mozilla-central/rev/eab2985673a5
The original patch's extend commit message describes that if a
AccessibleCaretEventHub registers scroll and reflow observers only on the leaf
docshell, it fails to update caret position when an ancestor iframe is
scrolled.
I think the above statement is incorrect. When scrolling an ancestor
iframe, the visible caret in an inner iframe should scroll with other
elements by virtue of APZ. Also, `AccessibleCaret::SetPosition()` itself
detects whether its position is changed relative to the top level
absolute position container (the moz-custom-content-container under
CanvasFrame). When scrolling an ancestor iframe, AccessibleCaret's
position in the inner iframe should remain static (relative to the inner
frame.)
Differential Revision: https://phabricator.services.mozilla.com/D84873
Erik Nordin
Hiroyuki Ikezoe
Glenn Watson
Emilio Cobos Álvarez
longsonr
Jamie Nicol
Csoregi Natalia
Botond Ballo
Sonia Singla
Sean Feng
Nika Layzell
Jonathan Watt
Daniel Holbert
Zeke Medley
Shinichi Morimoto
Boris Chiou
Narcis Beleuzu
Jared Wein
Ting-Yu Lin
Bogdan Tara