1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
<!DOCTYPE html><html class="reftest-paged">
<style>html{font-size:12pt}</style>
<!-- http example.org uri makes this an oop if with fission -->
<iframe style="height: 1000vh" src="http://example.org/1743533-1-helper.html">
</iframe>
</html>
<!--
Some notes about this test.
To reproduce the problem we just need an oop iframe that spans multiple pages,
and some content in it that also spans multiple pages. I used text instead
of a background color because background colors don't show up by default in
print preview. We're using page mode here and not print preview, so that is
not technically required here.
The most obvious way to test this would be to compare an oop iframe and an
in process iframe with the same content to make sure they are the same.
However, for some reason, in reftest-paged mode a simple in process iframe
seems to refuse to load the document, I think because of this code
https://searchfox.org/mozilla-central/rev/3c9369510cb883b9f08d5f9641e1233d2142f025/dom/base/nsFrameLoader.cpp#439
If the same iframe is oop then the document does load, this behaviour difference
seems like it might be a bug. If that bug is ever fixed (so that the oop iframe here fails to
load it's document) then writing a test to exercise the original bug here seems
like it would be impossible.
So we compare an oop iframe with content in it, to a blank iframe, and then
we use a high minimum accepted number of pixels differing in the fuzz. This
then makes sure the two documents differ by enough pixels.
And we skip running this test if fission is disabled, as that would just
compare two blank iframes, which is not useful.
note why we couldn't use other test types
I tried to write this as a wpt print reftest, it did not reproduce the bug.
I'm not sure what wpt reftests use to simulate printing, but I suspect it
is not similar enough to our print preview to trigger the bug.
I tried to add this as a test to layout/base/tests/chrome/test_printpreview.xhtml
but that is not feasible because that test runs as part of the mochitest-chrome
suite, which I'm told doesn't even run in e10s mode, and definitely does not get
run with fission, which is required to reproduce the bug.
-->
|
