diff options
Diffstat (limited to 'layout/reftests/bugs/1743533-1.html')
| -rw-r--r-- | layout/reftests/bugs/1743533-1.html | 42 |
1 files changed, 42 insertions, 0 deletions
diff --git a/layout/reftests/bugs/1743533-1.html b/layout/reftests/bugs/1743533-1.html new file mode 100644 index 0000000000..bf0607d9ec --- /dev/null +++ b/layout/reftests/bugs/1743533-1.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. +--> |