Bug 1743533. Add test. r=botond,hiro

Differential Revision: https://phabricator.services.mozilla.com/D132790
This commit is contained in:
Timothy Nikkel 2021-12-06 01:08:55 +00:00
Родитель 57a0ff75ad
Коммит 6a84a5b02a
4 изменённых файлов: 65 добавлений и 0 удалений

Просмотреть файл

@ -0,0 +1,17 @@
<html>
<head>
<style>
:root { color-adjust: exact }
html { background: green; }
</style>
</head>
<body>
<!-- just need some content with large height, use text because bg colors don't print by default -->
<script>
for (let i = 0; i < 1000; i++) {
document.body.appendChild(document.createTextNode("content"));
document.body.appendChild(document.createElement("br"));
}
</script>
</body>
</html>

Просмотреть файл

@ -0,0 +1,5 @@
<!DOCTYPE html><html class="reftest-paged">
<style>html{font-size:12pt}</style>
<iframe style="height: 1000vh">
</iframe>
</html>

Просмотреть файл

@ -0,0 +1,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.
-->

Просмотреть файл

@ -2108,4 +2108,5 @@ skip-if(Android) == 1727172-1.xhtml 1727172-1-ref.html
== 1727016-1.html 1727016-1-ref.html
!= 1730314-1.html 1730314-1-ref.html
fuzzy(0-3,0-3) fuzzy-if(Android,0-3,0-1901) fuzzy-if(winWidget,0-154,0-118) == 1738700-1.html 1738700-1-ref.html
skip-if(Android||!browserIsFission) fuzzy(255-255,171000-171000) HTTP == 1743533-1.html 1743533-1-ref.html # do not decrease the fuzz! this is a not equal test, the high fuzz minimum is to ensure they differ by enough.
== 1743560-1.html 1743560-1-ref.html