The displayport is aligned to screen pixels by an alignment number; there was
code to increase that alignment number for the WebRender codepath. This is
desirable because it causes the displayport to move less frequently, which
provides better performance characteristics with WebRender. However, the
way that was implemented, it was possible for the aligned displayport to not
completely enclose the unaligned displayport, which could then result in
perma-checkerboarding.
This patch removes that code and replaces it with a simpler approach to scale
up the existing alignment number by a factor based on the size of the scroller's
base rect (roughly how much of the scroller is visible to the user).
This does make the displayports larger, more so for scrollers with more visible
area. This has negative performance implications, so we mitigate that by also
scaling down the displayport margin multiplier by the same scaling factor. This
isn't perfect, but seems to work well enough in practice.
Differential Revision: https://phabricator.services.mozilla.com/D90503
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
This patch includes a couple of changes.
1) Notify contentful paint only during refresh driver ticks.
2) Not only the root document, sub document should also have their own
contentful paint entry.
3) Consider invisible text as contentful as well.
Differential Revision: https://phabricator.services.mozilla.com/D89498
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
We usually suppress background images in
nsCSSRendering::PaintStyleImageLayerWithSC, but that codepath isn't hit
by WebRender, so instead do it during display list building, the same
way we suppress background colors.
Differential Revision: https://phabricator.services.mozilla.com/D90278
We usually suppress background images in
nsCSSRendering::PaintStyleImageLayerWithSC, but that codepath isn't hit
by WebRender, so instead do it during display list building, the same
way we suppress background colors.
Differential Revision: https://phabricator.services.mozilla.com/D90278
When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert
```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#02: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```
This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.
Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.
Differential Revision: https://phabricator.services.mozilla.com/D89409
This is sad, but seems like the least bad option to enable desktop zooming scrollbars reasonable soon.
Depends on D89409
Differential Revision: https://phabricator.services.mozilla.com/D90181
When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert
```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#02: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```
This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.
Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.
Differential Revision: https://phabricator.services.mozilla.com/D89409
Doing rAF rAF flushApzRepaints is not enough to make sure that any potential scroll events are sent to content. The reason is that if the apz repaint request causes us to do scrolling on the main thread then the scrolling will be finished after flushApzRepaints, and the scroll event will be pending, but it's not sent until the next refresh driver tick. So we need to do at least one rAF after flushApzRepaints.
Differential Revision: https://phabricator.services.mozilla.com/D90035
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
This adds a ScrollPositionUpdate class. Code in nsGfxScrollFrame creates
instances of these classes every time the scroll generation is incremented,
and saves them to an array. The array is sent in the scroll metadata to the
compositor as part of a paint transaction.
Currently this data is not used at all on the APZ side, and exists alongside
(independently of) the existing scroll fields, so this patch should not have
any functional effects.
Differential Revision: https://phabricator.services.mozilla.com/D88741
We treat it exactly the same as -moz-broken. The pseudo-class is not
exposed to content, so I don't think we have a reason to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D89904
In the next part, I'm going to use ComputeSizeFlags as the arguments in
some ReflowInput's methods. Because nsIFrame.h includes ReflowInput.h,
to solve the circular dependency, ComputeSizeFlags needs to be moved to
somewhere else.
Also, revise the document for ComputeSizeFlag. The rest of the patch is
just dropping `nsIFrame::` and adding `mozilla::` as needed.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D89542
The test fixes all fell into the follow categories:
A) The test uses requestAnimationFrame to wait one frame and expects scrolling to be complete. With the desktop zooming scrollbars in order for the scrolling to show up on the main thread we need to send the scroll request to the compositor and then hear back from it via an apz repaint request (apz callback helper). Waiting on requestAnimationFrame will complete the first part, but not necessarily the second part. The fix is to wait for a scroll event.
B) Switching tests to wait for scroll events exposes another problem: the test can do things that cause a scroll in order to setup the test (and that may not be obvious that it causes a scroll) before actually proceeding to do the test and do something that causes a scroll and then checks for the scroll change of the second thing. Waiting for a requestAnimationFrame would include both those scrolls without desktop zooming scrollbars, but if we wait for a scroll event we will get the scroll event for the first thing which we are not interested in. So we need to make sure scroll events are cleared out before waiting for any scroll events. We do this by waiting two requestAnimationFrame's and waiting for apz to be flushed. We also use this when a test does something and it wants to test that scrolling is not performed.
The main thing that causes scrolling that may not be obvious: calling node.focus(). With stacks like:
from test_scroll_per_page.html
```
#01: mozilla::ScrollFrameHelper::CompleteAsyncScroll(nsRect const&, mozilla::ScrollOrigin) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d6cc0]
#02: mozilla::ScrollFrameHelper::ScrollToWithOrigin(nsPoint, mozilla::ScrollMode, mozilla::ScrollOrigin, nsRect const*, nsIScrollbarMediator::ScrollSnapMode) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d7732]
#03: mozilla::layout::ScrollAnchorContainer::ApplyAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4742913]
#04: mozilla::PresShell::FlushPendingScrollAnchorAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4650069]
#05: mozilla::PresShell::ProcessReflowCommands(bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x465742b]
#06: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656af8]
#07: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c]
#08: mozilla::PresShell::ScrollContentIntoView(nsIContent*, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4652b96]
#09: nsFocusManager::ScrollIntoView(mozilla::PresShell*, nsIContent*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1bedd1c]
#10: nsFocusManager::Focus(nsPIDOMWindowOuter*, mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, bool, nsIContent*) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be6be0]
#11: nsFocusManager::SetFocusInner(mozilla::dom::Element*, int, bool, bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be212f]
#12: nsFocusManager::SetFocus(mozilla::dom::Element*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be32ba]
#13: mozilla::dom::Element::Focus(mozilla::dom::FocusOptions const&, mozilla::dom::CallerType, mozilla::ErrorResult&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1aaf283]
#14: mozilla::dom::HTMLElement_Binding::focus(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x2d65f3b]
```
from editor/libeditor/tests/test_bug549262.html
```
#01: mozilla::ScrollFrameHelper::CompleteAsyncScroll(nsRect const&, mozilla::ScrollOrigin) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d6cc0]
#02: mozilla::ScrollFrameHelper::ScrollToWithOrigin(nsPoint, mozilla::ScrollMode, mozilla::ScrollOrigin, nsRect const*, nsIScrollbarMediator::ScrollSnapMode) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d7732]
#03: mozilla::PresShell::ScrollFrameRectIntoView(nsIFrame*, nsRect const&, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x46541bc]
#04: mozilla::PresShell::DoScrollContentIntoView() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4653776]
#05: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656b11]
#06: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c]
#07: mozilla::PresShell::ScrollContentIntoView(nsIContent*, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4652b96]
#08: nsFocusManager::ScrollIntoView(mozilla::PresShell*, nsIContent*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1bedd1c]
#09: nsFocusManager::Focus(nsPIDOMWindowOuter*, mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, bool, nsIContent*) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be6be0]
#10: nsFocusManager::SetFocusInner(mozilla::dom::Element*, int, bool, bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be212f]
#11: nsFocusManager::SetFocus(mozilla::dom::Element*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be32ba]
#12: mozilla::dom::Element::Focus(mozilla::dom::FocusOptions const&, mozilla::dom::CallerType, mozilla::ErrorResult&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1aaf283]
#13: mozilla::dom::HTMLElement_Binding::focus(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x2d65f3b]
```
C) Several tests use nsIDOMWindowUtils advanceTimeAndRefresh/restoreNormalRefresh and expect scrolling to be done after a call to advanceTimeAndRefresh. This is basically A), advanceTimeAndRefresh does a refresh driver tick but doesn't allow a repaint request to come back to the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D89403
The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
We were adding the unwriteable to the default margin. I was going to
consider not painting the headers / footers if they overlapped with the
content box of the page, but turns out our default configuration
overlaps slightly at the bottom, so I just punted on that.
Users can remove the headers / footers quite easily anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D89794
Mostly mechanical change, with some extra work where non-literal names are provided.
Also, when this is the only profiler call in a file, `#include "GeckoProfiler.h"` can be changed to `#include "mozilla/ProfilerMarkers.h"`.
Differential Revision: https://phabricator.services.mozilla.com/D89415
When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert
```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#02: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```
This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.
Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.
Differential Revision: https://phabricator.services.mozilla.com/D89409
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
sendKey uses our new relative scroll path that does the scroll by the apz. But we don't have any scroll event ordering expectations when apz is doing the scroll. We trade lossing those expectations for smoother apz scrolling.
So change the test to use a method that doesn't use our new relative apz scroll path and goes back to main thread scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D89402
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
We can have markers with empty cause stacks, if we keep the timer running
without calling EnsureTimerStarted() again.
Differential Revision: https://phabricator.services.mozilla.com/D85457
Content processes will now receive cached values for GetFontImpl() from the
parent process during initialization and whenever the theme changes.
This eliminates the use of several Win32k calls in content.
Differential Revision: https://phabricator.services.mozilla.com/D83406
As a bonus, this also fixes a pre-existing bug that we never cleared the
mPrefChangePendingNeedsReflow flag after using it, so future pref changes
that shouldn't need a reflow would still trigger one.
Depends on D84518
Differential Revision: https://phabricator.services.mozilla.com/D84519
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
This patch basically attempts to make clicking in the scrollbar track outside of the scrollthumb "work". Clicking in the scrollbar track usually does a page scroll via nsSliderFrame::PageScroll. This eventually ends up in ScrollFrameHelper::ScrollBy where we turn the request from a relative one ("scroll by a page") into an absolute one ("scroll to this position").
This page scroll is typically a smooth scroll and is currently done on the main thread/layout side. Once we start scrolling the visual viewport offset with the scrollbars we can no longer do this purely on the layout side, we at least need the help of the compositor side. I think the simplest way to do this is to hand the scroll request off to the compositor and have it handle the whole thing.
Now we need to consider the following situation: user clicks scrollbar track to page scroll, smooth scroll gets partway complete on the compositor, user clicks again on scrollbar track for a further page scroll. The main thread can't send an absolute scroll offset update request to the compositor at this point because it has outdated information (it needs a 'starting position' to add the page scroll offset amount) so it'll end up scrolling to the wrong place. It has to send a relative scroll offset update.
We already have a mechanism to send relative scroll offset updates. It is implemented by sending a base scroll offset and the desired scroll offset, and then on the compositor send the difference between those two is computed and then added to the scroll offset.
This patch creates a new mechanism (so called "pure relative") that just sends a relative offset update without any absolute scroll positions. The reason I did this is because the existing relative scroll offset update mechanism is not aware of visual viewport offsets, but rather only layout scroll position. For example, here
https://searchfox.org/mozilla-central/rev/8d55e18875b89cdf2a22a7cba60dc40999c18356/layout/generic/nsGfxScrollFrame.h#446
the value we use for the base scroll offset (mApzScrollPos) is set to the layout scroll position. It may be entirely reasonable to make this existing mechanism vv offset aware, but I wanted to implement something to get it working with a smaller chance of regressions to things that already exist and work. Ideally these two mechanims would be merged.
Differential Revision: https://phabricator.services.mozilla.com/D82688
This offset was reset in one of the two codepaths of D80723, but turns
out it's important for same-origin documents that are also
root-content-documents, like about: pages in the parent process, which
happened to hit the codepath that did _not_ reset it. :(
Differential Revision: https://phabricator.services.mozilla.com/D84584
It seems win7 sometimes displaces it slightly. We've hit this in the
past and it's not the point of the test so just get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D84597
Before my patches the background images in table-background-print didn't
seem to load on time.
I tried to make the images* tests non-fuzzy, but the <svg:image> really
ruined the deal. A bit of a shame that they fall into a subpixel
boundary because of page margins. So allow a bit of fuzz there rather
than spending another few days trying :)
Differential Revision: https://phabricator.services.mozilla.com/D84516
We need to set the original document ASAP so images triggered from the
clone use the right service worker.
It is a bit unfortunate to have the static document checks twice, but we
may get to Document::GetClientInfo before the cloned doc has a window,
so it's not 100% clear to me how we could avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D82081
Otherwise my test fails intermittently on CI. We need to block on all
the load blockers because stuff like responsive images doesn't fire the
load directly but they do that as a micro task (blocking the load
event).
Differential Revision: https://phabricator.services.mozilla.com/D81989
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
Before my patches the background images in table-background-print didn't
seem to load on time.
I tried to make the images* tests non-fuzzy, but the <svg:image> really
ruined the deal. A bit of a shame that they fall into a subpixel
boundary because of page margins. So allow a bit of fuzz there rather
than spending another few days trying :)
Differential Revision: https://phabricator.services.mozilla.com/D84516
We need to set the original document ASAP so images triggered from the
clone use the right service worker.
It is a bit unfortunate to have the static document checks twice, but we
may get to Document::GetClientInfo before the cloned doc has a window,
so it's not 100% clear to me how we could avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D82081
Otherwise my test fails intermittently on CI. We need to block on all
the load blockers because stuff like responsive images doesn't fire the
load directly but they do that as a micro task (blocking the load
event).
Differential Revision: https://phabricator.services.mozilla.com/D81989
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
nsPreContext::mDynamicToolbarHeight is representing the state of the dynamic
toolbar in transition or is being collapsed. So if we leave the value as it is,
we misrecognize the state, the visual viewport width/height are significantly
affected by the misrecognition, it returns 0 because in the collapsed or the
transition state, it returns the special value [1] which is never properly set
without calling nsPresContext::UpdateDynamicToolbarOffset.
This mismatching state doesn't much matter in the real sites since we don't
often change the max height of the dynamic toolbar but in automated tests it's
a big problem. In fact a test case which will be introduced in the next commit
will not work properly without this fix.
[1] https://searchfox.org/mozilla-central/rev/1b95a0179507a4dc7d4b0c94c2df420dc1a72885/dom/base/VisualViewport.cpp#78
Differential Revision: https://phabricator.services.mozilla.com/D83902
Instead add a pseudo-class that does the expected size="" attribute parsing.
Removing the Gtk-specific rule setting the text color since it doesn't
seem to have any effect currently.
Differential Revision: https://phabricator.services.mozilla.com/D83448
This is going to be useful for the new print preview UI, which is in a
doorhanger and thus much more likely to be less than the page size.
We (ab)use the existing print preview scaling mechanism. We only need it
after reflowing all pages, so this works.
This whole scaling mechanism is all-in-all not amazing, but the patch is
less gross than I initially thought. It's nice, actually.
We could put the new behavior behind a pref trivially, if that's wanted,
but I honestly thing this behavior is better even without the doorhanger
ui.
Differential Revision: https://phabricator.services.mozilla.com/D83309
Per documentation, `aPositionedFrame` (the second argument) of
`PushAbsoluteContainingBlock` should be the frame whose style actually
makes the new absolute containing block a containing block, so it should
be the fieldset frame itself, not fieldset's inner frame.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D82651
- Add macOS-specific function to retrieve the paper list for a given printer.
- Add JS test to ensure papers are initialized with valid values.
Differential Revision: https://phabricator.services.mozilla.com/D82598
- Add macOS-specific function to retrieve the paper list for a given printer.
- Add JS test to ensure papers are initialized with valid values.
Differential Revision: https://phabricator.services.mozilla.com/D82598
The fallback code in nsPrintJob::DoCommonPrint to create an nsIPrintSettings if
none is passed in is never used, since all callers pass a settings object.
However, to simplify future changes I'd like nsGlobalWindowOuter::PrintOuter to
stop creating and passing in its own default valued nsIPrintSettings object.
This patch makes the fallback code that DoCommonPrint calls do what
nsGlobalWindowOuter::PrintOuter does, and makes the latter stop passing in a
settings object.
This patch also removes nsIWebBrowserPrint.globalPrintSettings since
nsGlobalWindowOuter::PrintOuter was its only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D83268
nsIWebBrowserPrint.globalPrintSettings returns a new object each time. That is
why the code in these tests doesn't work, and why they have the workaround to
set the pref to disable the progress dialog. This patch fixes the code and
removes the prefs setting workaround.
This patch also changes the code to use the print settings service to get the
print settings. That's all that nsIWebBrowserPrint.globalPrintSettings does
anyway. Making this change allows me to remove
nsIWebBrowserPrint.globalPrintSettings in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D83279
The fallback code in nsPrintJob::DoCommonPrint to create an nsIPrintSettings if
none is passed in is never used, since all callers pass a settings object.
However, to simplify future changes I'd like nsGlobalWindowOuter::PrintOuter to
stop creating and passing in its own default valued nsIPrintSettings object.
This patch makes the fallback code that DoCommonPrint calls do what
nsGlobalWindowOuter::PrintOuter does, and makes the latter stop passing in a
settings object.
This patch also removes nsIWebBrowserPrint.globalPrintSettings since
nsGlobalWindowOuter::PrintOuter was its only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D83268
- Add macOS-specific function to retrieve the paper list for a given printer.
- Add JS test to ensure papers are initialized with valid values.
Differential Revision: https://phabricator.services.mozilla.com/D82598
This fixes two issue.
First, the code shouldn't be dispatching these events every time it gets a new
Print or PrintPreview call. It only needs to dispatch the events to the
original document that we're going to clone from. When cloning from existing
static clones any changes made by 'beforeprint' will be present in the existing
static clone.
Second, the code tries to delay the 'afterprint' event until after
mozPrintCallback callbacks have been invoked, but those callbacks are invoked
in the cloned document, whereas the events are sent to the original document!
So there is no reason to do this.
Differential Revision: https://phabricator.services.mozilla.com/D34280
This fixes two issue.
First, the code shouldn't be dispatching these events every time it gets a new
Print or PrintPreview call. It only needs to dispatch the events to the
original document that we're going to clone from. When cloning from existing
static clones any changes made by 'beforeprint' will be present in the existing
static clone.
Second, the code tries to delay the 'afterprint' event until after
mozPrintCallback callbacks have been invoked, but those callbacks are invoked
in the cloned document, whereas the events are sent to the original document!
So there is no reason to do this.
Differential Revision: https://phabricator.services.mozilla.com/D34280
Jonathan Kew
Kartikaya Gupta
Botond Ballo
Kris Maglione
Olli Pettay
Dorel Luca
Emilio Cobos Álvarez
Timothy Nikkel
Sean Feng
Andreas Farre
Narcis Beleuzu
Barret Rennie
Mihai Alexandru Michis
Bas Schouten
Noemi Erli
Razvan Maries
Ting-Yu Lin
Gerald Squelart
Nicklas Boman
Bogdan Tara
Emilio Cobos Alvarez
lonocvb
Hiroyuki Ikezoe
Nathan Froyd
Jonathan Watt
Edgar Chen
Sylvestre Ledru
Cosmin Sabou
Mats Palmgren
Daniel Holbert
Stephen A Pohl
Honza Bambas
Bob Owen
Erik Nordin
Jamie Nicol
Csoregi Natalia
Boris Chiou
longsonr
Simon Giesecke
Brindusan Cristian
Emma Malysz
Kashav Madan
Butkovits Atila
Jeremy Ir
Markus Stange
Chris Liu
Chris Martin
Tim Nguyen
Cameron McCormack
Nicolas Silva
Philipp Zech
tkhan
Kagami Sascha Rosylight