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
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
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
The frame selection changes can run script, so we need to check for the
frame itself getting destroyed. This fixes the crash as reported.
Additionally, the document check it does for pointer capture is
incorrect, it should use the composed, not uncomposed doc, so that it
works in shadow dom.
Differential Revision: https://phabricator.services.mozilla.com/D87097
We run the widget initialization code regardless on bind, and some of it
doesn't deal with shadow roots being already populated.
Differential Revision: https://phabricator.services.mozilla.com/D86952
CLOSED TREE
Backed out changeset 17df14f0b129 (bug 1200896)
Backed out changeset 5d9e9bd12cd2 (bug 1200896)
Backed out changeset 7f016de8d52f (bug 1200896)
The call sites of nsDeviceContext::RegisterPageDoneCallback are in the parent
process along with the IsSyncPagePrinting check.
Differential Revision: https://phabricator.services.mozilla.com/D86868
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
Before bug 1657164 there was always some printer on Linux and this test
ran just fine.
We don't really need a printer to test print preview, the test works
just fine.
I noticed this while auditing the "lastPrinterName" checks.
Differential Revision: https://phabricator.services.mozilla.com/D86404
This is strictly better and more flexible, but can change specificity so
have a pref in case it causes trouble. I doubt it will though, the
specificity rules of :is() make more sense, and my gut feeling is that
:-moz-any is not very used on the wild.
Make it early-beta-or-earlier for now to minimize risk, once this is on
nightly for a bit we can enable it everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D86696
And fix the only WPT for this while at it which was using the wrong URL
(and thus would always pass).
This actually makes me a bit uncomfortable given the amount of times
I've seen the pattern:
<link href="important.css" rel="preload" as="style" onload="this.rel = 'stylesheet'">
As that means that important.css won't block the load event. But let's
try.
Differential Revision: https://phabricator.services.mozilla.com/D86049
Also, for changes in CSS declarations, like changing
cssRules[i].style.color or something, we end up avoiding a lot of the
work we were doing.
This page still trips us in the sense that they add a stylesheet, then
call getBoundingClientRect(), then insert more rules in the stylesheet,
which causes us to rebuild a lot of the cascade data.
We could try to detect appends to the last stylesheet on the list or
something I guess, and avoid rebuilding the cascade data in some cases.
Depends on D85615
Differential Revision: https://phabricator.services.mozilla.com/D85616
I intentionally removed the "move the default printer to the front" in
windows because that's not a guarantee that we provide in CUPS, but lmk
if you want it back.
I have zero idea about why the GlobalPrinters code was so ridiculously
complex.
Depends on D86396
Differential Revision: https://phabricator.services.mozilla.com/D86397
That prevents preceding whitespace from getting collapsed.
When there's a single lone CR (so `a\rb`) our behavior here diverges
from Chrome's but matches Safari's. We treat it as ZWSP.
That matches the initial resolution of [1], but then there have been
various doing and undoings of that resolution, so it's not totally clear
to me what the correct behavior per spec should be. I think "treat it as
other control character"? But I haven't dug into what that implies, so
for now I've just kept behavior there as-is.
[1]: https://github.com/w3c/csswg-drafts/issues/855
Differential Revision: https://phabricator.services.mozilla.com/D86188
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
The existing calculation will make them overlap. The AdjustOverlappingScrollbars code was written with overlay scrollbars in mind but it looks like it will work just fine for this case.
Differential Revision: https://phabricator.services.mozilla.com/D85707
Otherwise the calculation above would lead to an empty rect for the scroll corner.
The scrollbar rects as computed now still overlap each other and the scroll corner, the next patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D85706
There is no dependency in this code as far as I can tell.
The next patch needs the scrollbar rects for the scroll corner calculation.
Differential Revision: https://phabricator.services.mozilla.com/D85705
Layout scrollbars that were only created for the visual viewport had no space reserved for them, so we need to shift them back in like overlay scrollbars. Otherwise they sit just outside of the scroll port and are not visible.
Differential Revision: https://phabricator.services.mozilla.com/D85704
For the former we are still allowed to show scrollbars if we need to scroll the visual viewport inside the layout viewport (as long as they take up no layout space). For the latter we still do not want to show scrollbars.
The ShowScrollbar enum is now only from layouts perspective and doesn't take into account anything about the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D85700
This will actually regress behaviour when overflow is auto and pinch zooming creates scrollable overflow (scrolling the visual viewport inside the layout viewport). We will fix that in later patches.
The reason that this is necessary is that the code as-is is incorrect if we have layout scrollbars (scrollbars that take up space). If we have layout scrollbars and we pinch zoom and we go from not needing a scrollbar to needing a scrollbar then that scrollbar cannot take up layout space (even though it is a layout scrollbar). The scrollbar cannot change the size of the layout viewport (it does, however, change the size of the visual viewport).
In later patches we fix this situation as well as the situation with an overflow hidden document (which also needs to create scrollbars when pinch zoomed).
Differential Revision: https://phabricator.services.mozilla.com/D85699
When a clearance frame is discovered in a BFC
subtree (`ReflowInput::WillReflowAgainForClearance()` is true), all the
block descendants of the BFC return from `ReflowBlockFrame` immediately
without placing their children or requesting continuation for their
children, etc., because the BFC is going to reflow the subtree a
second time.
When this happens, any block descendant whose lines contain pushed
floats should be marked dirty and reflowed again so that they can go
through all the split floats logic and set their nsReflowStatus to
incomplete/overflow-incomplete correctly. (We may develop a smarter way
in bug 851629 to make the performance better.)
The condition `aState.mPresContext->IsPaginated()` is added to prevent
1406291-1.html from failing. In 1406291-1.html, the table containing the
float in its subtree is being pushed to the second page due to force
break, and the float is in PushedFloatsList of its parent block. When we
reflow the block again (in the second page), it is reflowed under the
measuring stage of the table layout with unconstrained available
block-size. nsBlockFrame::DrainSelfPushedFloats() deliberately doesn't
drain pushed floats if their placehoder are in the same block, and
expect the floats to be reflowed again. Before this patch, the line can
be marked dirty via HasPushedFloats(), but in this patch,
HasPushedFloats() is moved into the nested if-else, so we need
`aState.mPresContext->IsPaginated()` to let the block know that it's in
a paginated context, and needs to reflow any line that contains pushed
floats.
Differential Revision: https://phabricator.services.mozilla.com/D85480
Before this patch, a block frame considers a line dirty only if the line's
block-end is larger than content area's block-end.
However, scrollable overflow area should be broken in paginated environment
(both in a column container and in printing). We should take this into account
when marking a line dirty.
The dynamic wpt reftests are written with the following conditions in mind to
expose the bug:
1. Initially, all the elements fit into the first column.
2. After shrinking the multicol height, the block itself still fits into
the first column, but its tall child (either a simple tall block or a
tall float), which overflows the smaller multicol height, needs to be
broken.
The flexbox printing reftest are similar. A flex container uses
unconstrained available block-size to measure flex items' block-size,
and then performs a final reflow with constrained available block-size,
which is similar to the dynamic scenario above. One caveat is that flex
items usually have IsBResize() set. So to expose this bug, a float
element needs to be deeply nested under a flex item.
Differential Revision: https://phabricator.services.mozilla.com/D85479
Today we don't require that `mach` `CommandProvider`s subclass from any particular parent class and we're very lax about the requirements they must meet. While that's convenient in certain circumstances, it has some unfortunate implications for feature development.
Today the only requirements that we have for `CommandProvider`s are that they have an `__init__()` method that takes either 1 or 2 arguments, the second of which must be called `context` and is populated with the `mach` `CommandContext`. Again, while this flexibility is occasionally convenient, it is limiting. As we add features to `mach`, having a better idea what the shape of our `CommandProvider`s are and how we can instantiate them and use them is increasingly important, and this gives us additional control when having `mach` configure `CommandProvider`s based on data that is only available at the `mach` level. In particular, we plan to leverage this in bugs 985141 and 1654074.
Here we add validation to the `CommandProvider` decorator to ensure all classes inherit from `MachCommandBase`, update all `CommandProvider`s in-tree to inherit from `MachCommandBase`, and update source and test code accordingly.
Follow-up work: we now require (de facto) that the `context` be populated with a `topdir` attribute by the `populate_context_handler` function, since instantiating the `MachCommandBase` requires a `topdir` be provided. This is fine for now in the interest of keeping this patch reasonably sized, but some additional refactoring could make this cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D86255
This restricts the workaround to mobile a bit better, since the
GetIsViewportOverridden() check returns true on desktop as of bug 1644271.
Differential Revision: https://phabricator.services.mozilla.com/D86414
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
The existing calculation will make them overlap. The AdjustOverlappingScrollbars code was written with overlay scrollbars in mind but it looks like it will work just fine for this case.
Differential Revision: https://phabricator.services.mozilla.com/D85707
Otherwise the calculation above would lead to an empty rect for the scroll corner.
The scrollbar rects as computed now still overlap each other and the scroll corner, the next patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D85706
There is no dependency in this code as far as I can tell.
The next patch needs the scrollbar rects for the scroll corner calculation.
Differential Revision: https://phabricator.services.mozilla.com/D85705
Layout scrollbars that were only created for the visual viewport had no space reserved for them, so we need to shift them back in like overlay scrollbars. Otherwise they sit just outside of the scroll port and are not visible.
Depends on D85703
Differential Revision: https://phabricator.services.mozilla.com/D86332
For the former we are still allowed to show scrollbars if we need to scroll the visual viewport inside the layout viewport (as long as they take up no layout space). For the latter we still do not want to show scrollbars.
The ShowScrollbar enum is now only from layouts perspective and doesn't take into account anything about the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D85700
This will actually regress behaviour when overflow is auto and pinch zooming creates scrollable overflow (scrolling the visual viewport inside the layout viewport). We will fix that in later patches.
The reason that this is necessary is that the code as-is is incorrect if we have layout scrollbars (scrollbars that take up space). If we have layout scrollbars and we pinch zoom and we go from not needing a scrollbar to needing a scrollbar then that scrollbar cannot take up layout space (even though it is a layout scrollbar). The scrollbar cannot change the size of the layout viewport (it does, however, change the size of the visual viewport).
In later patches we fix this situation as well as the situation with an overflow hidden document (which also needs to create scrollbars when pinch zoomed).
Differential Revision: https://phabricator.services.mozilla.com/D85699
We want this to be turned on for nightly users by default. The page range is still a WIP,
so we should hide that section for now.
This also adds the pref to the "Nightly Experiment" panel, turned on by default.
Differential Revision: https://phabricator.services.mozilla.com/D85907
UpdateScrollbarPosition and ReflowFinished both use the scroll range for this. It usually doesn't matter, but the next patch will make it important.
Differential Revision: https://phabricator.services.mozilla.com/D85983
The COOP header is set to BrowsingContext only in Document::StartDocumentLoad.
If the replaced document has a different COOP header from one in its docshell.
Then, we can crash while creating a window global child for a new inner window.
Differential Revision: https://phabricator.services.mozilla.com/D85127
There's no reason this shouldn't work per the grid spec.
We also remove some outdated condition on the meaning of
align/justify-self: normal on grid items without aspect ratio. This
matches the behavior of other browsers, and the spec as far as I can
tell.
https://drafts.csswg.org/css-grid/#grid-item-sizing no longer mentions
'stretch' from the definition of 'normal'.
Differential Revision: https://phabricator.services.mozilla.com/D85435
This is no worse than what we were doing.
In the future, instead of just querying the margin we may want to query
extra information that requires a DC in windows too or what not, for
example.
Differential Revision: https://phabricator.services.mozilla.com/D85919
This builds on top of bug 1656146 to compute the page information on a
background task, and return it via a promise.
Co-Authored-By: Erik Nordin <enordin@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D85865
The abstract observer base classes are moved to a separate header file
nsRefreshObservers.h and the includes are adjusted accordingly.
Some method implementations are moved to the corresponding implementation files
to avoid the need to include the nsRefreshDriver.h file in the header.
Differential Revision: https://phabricator.services.mozilla.com/D85764
This patch:
- Creates an anon-box pseudo-style for PrintedSheetFrame, in part so that it
can co-opt the styles that we formerly gave to page-frames in ua.css, to draw
the sheet of paper and the shadow in Print Preview.
- Adjusts nsCSSFrameConstructor to create a PrintedSheetFrame as the parent of
nsPageFrame (inserting between it and its nsPageSequenceFrame container, in
the frame tree).
- Fleshes out out a simple BuildDisplayList() implementation for
PrintedSheetFrame (taking the responsibility for "paper"-drawing from
nsPageFrame).
- Fleshes out a simple Reflow implementation for PrintedSheetFrame, just
placing the child page (assuming there's only one for now) at the origin.
- Adjusts nsPageFrame and nsPageSequenceFrame to account for the fact that
there's another layer between them now.
Note that PrintedSheetFrame needs to implement AppendDirectlyOwnedAnonBoxes()
(just as nsSimplePageSequence and nsPageFrame do), since it owns anonymous
nsPageFrame instances. This implementation only needs to append the first
child, as explained in the code-comment and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1374761#c9 (and of course, for
now, PrintedSheetFrame only has one child at a time anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D83457
This patch is just to get the "new file/frame class" boilerplate out of the
way. As of this patch, this frame class *is* compiled, but it doesn't do
anything and it's never instantiated. The next patch in this series will make
us actually start using it at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D83456
The COOP header is set to BrowsingContext only in Document::StartDocumentLoad.
If the replaced document has a different COOP header from one in its docshell.
Then, we can crash while creating a window global child for a new inner window.
Differential Revision: https://phabricator.services.mozilla.com/D85127
Before this patch, we used a clumsy "GetNextPage" helper-function (which,
despite its name, actually gets the next page **content** frame). It worked by
pointer-chasing to get the parent's next-sibling's first-child. This is
unnecessary; we can just directly query for the nsPageContentFrame's
next-continuation, since these frames are linked in a straightforward
continuation chain.
Note that GetNextContinuation() is a virtual function-call, but it may still be
faster than the pointer-chasing that we were doing with the GetNextPage()
API. Moreover, we can help the compiler devirtualize it by static_cast'ing to
the concrete type before calling the method. This is safe since nsPageFrame
always contains a single nsPageContentFrame (which we already validate -- at
least the frame-type-part -- via assertions).
Differential Revision: https://phabricator.services.mozilla.com/D85802
The issue here is that AccessibleCaret flushes layout from the middle of
the SetValue call, because it hides the caret (see the call stack in
comment 11).
That changes the placeholder-shown state because it goes from empty to
non-empty but the SetValue call from UnbindFromFrame is not supposed to
change that state (because we're in the middle of restyling).
Call OnValueChanged later, at the outer caller instead.
Differential Revision: https://phabricator.services.mozilla.com/D85745
While at it, properly CC the printer classes, as they're going to hold
promises and it's very easy to introduce leaks otherwise.
Co-Authored-By: Jonathan Watt <jwatt@jwatt.org>
Differential Revision: https://phabricator.services.mozilla.com/D85791
This also refactors the selection printing code, so that as we build the tree we
record which nsPrintObject should be used if printing a Selection is chosen.
Differential Revision: https://phabricator.services.mozilla.com/D85600
Retrieve paper size information directy from CUPS.
- Add unwriteable margins tests.
- Rename nsPaper to nsPaperCUPS.
- Add new functionality to nsCUPSShim.
- Retrieve paper info from CUPS
Differential Revision: https://phabricator.services.mozilla.com/D85211
This also refactors the selection printing code, so that as we build the tree we
record which nsPrintObject should be used if printing a Selection is chosen.
Differential Revision: https://phabricator.services.mozilla.com/D85600