Previously, tagged PDF generation required that something else had already created the accessibility service.
If the accessibility service wasn't running, we simply didn't create a tagged PDF.
Now that the accessibility service can be created in a stripped-down mode for PDF output, make DocManager::NotifyOfPrintDocument into a static method which creates the accessibility service appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D299961
Motivation: MakeAndAddRef forces us to store the result in a refcounted
pointer, which is a nice safety/strictness improvement. Also, migrating lets
us reduce the number of manual 'new' invocations, which reduces our audit
surface for memory-allocation/lifetime issues.
Differential Revision: https://phabricator.services.mozilla.com/D299010
1. Notify accessibility about a document that is being printed so it can build the accessibility tree and initialize PdfStructTreeBuilder.
2. If there are OOP iframes, wait for their accessibility trees to arrive async before proceeding with printing. Unfortunately, SkPDF requires the struct tree when it is initialised, so we can't do this during printing the way we do with CrossProcessPaint.
3. PrintTargetSkPDF uses PdfStructTreeBuilder to build the struct tree and pass it to SkPDF.
4. When printing is finished (done or aborted), PrintTargetSkPDF notifies PdfStructTreeBuilder that it is done so the builder can be cleaned up.
Although the struct tree is generated, it isn't associated with any of the printed content yet.
We'll do that in the next patch.
Note that this requires that the accessibility engine is enabled, which means an accessibility client needs to be running or the engine needs to be force enabled.
If it isn't, tagged PDF output will be disabled.
Fixing this will require adjustments to the accessibility engine which will be handled in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D285960
In order to generate tagged PDF later, we need the ability to associate printed content with semantic document content.
The BrowsingContext id is the easiest way to do this without too much coupling of modules.
Differential Revision: https://phabricator.services.mozilla.com/D285957
This reverts commit 864e3ed1ca.
Revert "Bug 1657973 part 5: Hook up PdfStructTreeBuilder to the layout and gfx code. r=emilio,lsalzman,layout-reviewers"
This reverts commit 50abf9d6c3.
Revert "Bug 1657973 part 4: Hook up PdfStructTreeBuilder to the printing and PDF code. r=layout-reviewers,dshin"
This reverts commit f600fda75a.
Revert "Bug 1657973 part 3: Accessibility engine changes required for PdfStructTreeBuilder. r=eeejay"
This reverts commit 5a036cc26e.
Revert "Bug 1657973 part 2: Add PdfStructTreeBuilder. r=eeejay"
This reverts commit 8d98b7bed1.
Revert "Bug 1657973 part 1: Plumb BrowsingContext id to PrintTargetSkPDF::BeginPrinting and make it available to nsDeviceContext::End/AbortDocument. r=emilio,geckoview-reviewers,win-reviewers,layout-reviewers,gstoll,m_kato"
This reverts commit cc79f1945a.
1. Notify accessibility about a document that is being printed so it can build the accessibility tree and initialize PdfStructTreeBuilder.
2. If there are OOP iframes, wait for their accessibility trees to arrive async before proceeding with printing. Unfortunately, SkPDF requires the struct tree when it is initialised, so we can't do this during printing the way we do with CrossProcessPaint.
3. PrintTargetSkPDF uses PdfStructTreeBuilder to build the struct tree and pass it to SkPDF.
4. When printing is finished (done or aborted), PrintTargetSkPDF notifies PdfStructTreeBuilder that it is done so the builder can be cleaned up.
Although the struct tree is generated, it isn't associated with any of the printed content yet.
We'll do that in the next patch.
Note that this requires that the accessibility engine is enabled, which means an accessibility client needs to be running or the engine needs to be force enabled.
If it isn't, tagged PDF output will be disabled.
Fixing this will require adjustments to the accessibility engine which will be handled in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D285960
In order to generate tagged PDF later, we need the ability to associate printed content with semantic document content.
The BrowsingContext id is the easiest way to do this without too much coupling of modules.
Differential Revision: https://phabricator.services.mozilla.com/D285957
We wrap the list of timelines attached to the document into a controller,
so this makes it easier to support diffrerent types of timelines, e.g.
scroll-timeline.
We will add the implementation of scroll timelines in the following
patches.
Differential Revision: https://phabricator.services.mozilla.com/D269663
We wrap the list of timelines attached to the document into a controller,
so this makes it easier to support diffrerent types of timelines, e.g.
scroll-timeline.
We will add the implementation of scroll timelines in the following
patches.
Differential Revision: https://phabricator.services.mozilla.com/D269663
After the previous patches, nsViewManager is basically a backpointer to
its pres shell.
Remove it and just make PresShell manage the root view directly. After
this is done, we can decide what to do about nsView (which is itself
little more than a widget listener that forwards to pres shell right
now).
This technically starts listening to mParentWidget slightly later (on
pres shell creation), but I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D272890
No need to reposition views during layout and so on, now that we don't
use views for either popups nor subdocuments.
No need for nsView to have parent / sibling / children either.
Differential Revision: https://phabricator.services.mozilla.com/D271205
This allows to clean up even more view code, since views now are just a
link between layout and widget at the root and little else (so the whole
view children and so on can go), but that will be done in separate
patches since these patches are not risk-free.
Notable changes:
* PresShell::WillPaint() now recurses into subdocuments. That was done
previously via CallWillPaintOnObservers().
* Embedder frame is tracked directly by nsSubDocumentFrame an
PresShell. It might be possible to simplify this further,
if bug 1997773 sticks.
Differential Revision: https://phabricator.services.mozilla.com/D232057
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
We always attach to the top-level widget / never create child popups.
On child processes this is already asserted via nsIWidget::CreateChild,
and on the parent nowadays our behavior would be nonsensical (we'd
create a separate nsCocoaWindow etc).
Differential Revision: https://phabricator.services.mozilla.com/D268976
... Instead of deleting them outright. Adjust the toolkit print selection test
to use use innerText instead of textContent to reflect this.
See documentation for nsRange::SuppressContentsForPrintSelection for why.
Differential Revision: https://phabricator.services.mozilla.com/D255165
https://phabricator.services.mozilla.com/D251609 introduces a new type
to `RangeBoundary` so that it has different behaviours for
`TreeKind::DOM` and `TreeKind::Flat`. There was a concern about
mix-using the boundaries that had different types, it would be
error-prone.
The idea to address that concern is we always keep nsRange::mStart
and nsRange::mEnd to use `TreeKind::DOM`, and make
CrossShadowBoundaryRange to always use `TreeKind::Flat`. This also means
that we need to create CrossShadowBoundaryRange more often.
Differential Revision: https://phabricator.services.mozilla.com/D254081
When a user is hitting mysterious print errors, this marker (particularly its
backtrace) may help us get closer to understanding the cause of the print error
from a performance profile. It at least lets us know which
FirePrintingErrorEvent() callsite is responsible.
Differential Revision: https://phabricator.services.mozilla.com/D245982
Printing has a weird code-path which doesn't use the refresh driver.
Update frame sizes explicitly, and remove the hack in
nsDisplayRemote::Paint (which is what probably papered over this).
Differential Revision: https://phabricator.services.mozilla.com/D222372
James Teh