1309046 - SVG with external content via <use> does not print

Status: NEW

(Core :: Printing: Output, defect, P3)

Description

[Craig McGinley]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce:

My application uses an SVG icon sprite sheet, which is useful for caching. I am using svg4everybody for certain browsers but this shouldn't affect Firefox.

I include icons in the page similar to this:
<svg class="icon">
    <use xlink:href="/img/icon-sprite.svg#icon-name"/>
</svg>

You can also reference here for an example, same method:
https://css-tricks.com/examples/svg-for-everybody/


Actual results:

As far as I can tell, all SVG's with external content via <use> do not print.


Expected results:

I would expect the SVG images to still print, as they do in all other browsers I tested (IE/safari/chrome).

Comment 1

[Craig McGinley]

I should add that the SVG's appear just fine on the webpage. This is only concerned with printing the webpage, where the SVG's then disappear.

Comment 2

[Loic]

Print Preview is affected too. Like older versions (FF29 e.g.), surely a duplicate.

Comment 3

[Caleb]

I can confirm this (Windows 10 Creators, Firefox 53.0).

Comment 4

[CHITRA]

I can confirm the same in (Windows 10, Firefox 54.0.1). Print Preview is affected.

Comment 5

[CHITRA]

I can confirm the same in Mac Sierra, Firefox 55. Print Preview is affected.

Comment 6

[Astley Chen (inactive)]

CJ, any idea on why?

Comment 7

[u459114]

We can also use this example for testing
https://searchfox.org/mozilla-central/source/layout/reftests/svg/use-localRef-clipPath-01.svg

Comment 8

[u459114]

Update what I found so far:
1. While printing a web page, we will create a new document and use a nsSimplePageSequenceFrame as a root container.
2. Layout: there are several use elements in the test example, so I set a break pointer in  SVGUseElement::CreateAnonymousContent[ to check whether we create  anonymous content for reference target. We early return at [1] which means we do not create an anonymous use element tree.

[1]
https://searchfox.org/mozilla-central/source/dom/svg/SVGUseElement.cpp#221

Comment 9

[u459114]

nsDataDocumentContentPolicy::ShouldLoad(...) {
  ....
  if (doc->IsLoadedAsData()) {
    // ...but let static (print/print preview) documents to load fonts.
    if (!doc->IsStaticDocument() || aContentType != nsIContentPolicy::TYPE_FONT) { << reject here!
      *aDecision = nsIContentPolicy::REJECT_TYPE;
      return NS_OK;
    }
  }
}

Comment 10

[u459114]

Attachment: Bug 1309046 - WIP.

Review commit: https://reviewboard.mozilla.org/r/201150/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/201150/

Comment 11

[u459114]

Comment on attachment 8929981 [details]
Bug 1309046 - WIP.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/201150/diff/1-2/

Comment 12

[u459114]

Attachment: Bug 1309046 - WIP.

Review commit: https://reviewboard.mozilla.org/r/201152/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/201152/

Comment 15

[u459114]

Attachment: Another WIP

Comment 16

[u459114]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e5d57c5c2e308cfe55eb45f5506922d31684ddd9

Comment 17

[u459114]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c8079301de242f997ad8e4c7db464f8b0b18a126

Comment 18

[u459114]

Update what I had found know
1. When print, we create a static clone document from the original one for printing. This new cloned one is 
   a. a data document [1]
   b. a static document.[2]

2. In the test cases, there are several <use> elements inside this document. Each of them will request a exteranl resource from an SVG file, e.g. <use href="foo.svg#svg_element_id">
3. security checking for these request: since the cloned document is a data document(see #1), it basically can not load any content, except of nsIContentPolicy::TYPE_DTD and nsIContentPolicy::TYPE_FONT type [3].

[1]
https://hg.mozilla.org/mozilla-central/file/b828f7a6c2bf/dom/base/nsDocument.cpp#l9813
[2]
https://hg.mozilla.org/mozilla-central/file/905239391e05/layout/printing/nsPrintObject.cpp#l87
[3]
https://hg.mozilla.org/mozilla-central/file/952640eb7c56/dom/base/nsDataDocumentContentPolicy.cpp#l73

Comment 19

[u459114]

Update what I had found now
1. When print, we create a static clone document from the original one for printing. This new cloned one is 
   a. a data document [1]
   b. a static document.[2]

2. In the test cases, there are several <use> elements inside this document. Each of them will request a exteranl resource from an SVG file, e.g. <use href="foo.svg#svg_element_id">[3]
3. security checking for these request: since the cloned document is a data document(see #1), it basically can not load any content, except of nsIContentPolicy::TYPE_DTD and nsIContentPolicy::TYPE_FONT type [4].

[1]
https://hg.mozilla.org/mozilla-central/file/b828f7a6c2bf/dom/base/nsDocument.cpp#l9813
[2]
https://hg.mozilla.org/mozilla-central/file/905239391e05/layout/printing/nsPrintObject.cpp#l87
[3]
https://hg.mozilla.org/mozilla-central/file/5ebe2e8980c6/dom/base/IDTracker.cpp#l104
[4]
https://hg.mozilla.org/mozilla-central/file/952640eb7c56/dom/base/nsDataDocumentContentPolicy.cpp#l73

Comment 20

[Sebastian Simon]

Currently, in the Nightly, pages that have a <use> element are just unable to be printed. Two error dialogs shows up, saying “Printer [or ‘Print Preview’] error” – “An unexpected problem occured when printing.” and in the browser console, this error shows up:

In Printing:Print:Done handler, got unexpected rv                                 PrintingChild.jsm:358
                        2147549183.
  print                                                   resource://gre/actors/PrintingChild.jsm:358:9
  receiveMessage                                           resource://gre/actors/PrintingChild.jsm:98:9
  receiveMessage                                     resource://gre/modules/ActorManagerChild.jsm:91:39

Is this the same issue, or is it a new one?