505437 - Reftest failures when run against Thunderbird.

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Mark Banner (:standard8)]

I've just been running the reftests against TB 3b3 build 1 and TB 3b4pre on Mac. These are both showing the same reftest failures. Additionally TB 3b3 build 1 on Linux also shows the failures.

Tests 315920-18d.html and 315920-18g.html appear to hang and don't continue (afaict).

With those removed, the following test failures are shown:

REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/bugs/289480.html#top |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/page-as-data.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/page-as-data-with-type.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/image.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/image-with-type.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/image-no-useful-extension-typesniff.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/image-no-useful-extension-with-type.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/type-overridden-by-server.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/malformed-xml.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/malformed-xml-with-type.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/svg/sizing/object--auto-auto--0-0.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/svg/sizing/object--auto-auto--0-pct.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/svg/sizing/object--auto-auto--0-px.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/svg/sizing/object--auto-auto--pct-0.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/svg/sizing/object--auto-auto--px-0.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/svg/sizing/object--auto-auto--px-px.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/svg/sizing/dynamic--object-svg-unloaded.xhtml | timed out waiting for reftest-wait to be removed (after onload fired)
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/svg/pseudo-classes-02.svg |
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/content/html/content/reftests/468263-1c.html | (!=)
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/moztest/comm/tests/reftest/tests/content/html/content/reftests/468263-1d.html | (!=)

The vast majority of these are using the <object> element to load something else in which will then cause the test to pass.

I have run a few of the tests on a debug build with NSPR_LOG_MODULES=nsContentPolicy:5 set in the environment and it is clear that the content policy is rejecting the load of the items referred to in those elements.

What isn't clear is that I tried loading these tests into Thunderbird:

Components.classes['@mozilla.org/appshell/window-mediator;1'].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("mail:3pane").document.getElementById("tabmail").openTab("contentTab", {contentPage: "file:///Users/moztest/comm/tests/reftest/tests/layout/reftests/object/page-as-data.html"});

and I believe they passed (they showed "PASS" rather than "FAIL"). Also loading into a new window via Thunderbrowse passed as well.

I think we need a bit more debugging on this, however my instinct is telling me this probably doesn't block beta 3 but blocks rc1.

If someone has time, could they try getting the page-as-data.html and its "extra/pass.html" additional file onto an http server and loading that in via an http:// link using a variant of the above?

Comment 1

[Mark Banner (:standard8)]

See url for how I was running them.

Comment 2

[Philippe M. Chiasson (:gozer)]

I've copied these files to : <http://ectoplasm.org/tmp/bug505437/page-as-data.html>

Comment 3

[Philippe M. Chiasson (:gozer)]

Tried with 3.0b3 on Linux : FAIL

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

This definitely does not block rc3, and I'm even on the fence about RC1 until we have a good feel of the exactly how common this is in web content.  My assumption is that nobody counts on email content to support <object>.

Comment 5

[Mark Banner (:standard8)]

I guess there is something in my profile making this work. As with a different profile on Mac it fails. Which means I see failures on all platforms.

Comment 6

[Philippe M. Chiasson (:gozer)]

Tried with 3.0b3 on Mac OS X: FAIL

Both my attempts are with Go => Thunderbird Start Page

Comment 7

[Mark Banner (:standard8)]

(Not blocking due to minimal impact on most people as this shouldn't affect general mail reading).

Comment 8

[Mark Banner (:standard8)]

I've just been looking at this a bit more. The behaviour here should be the same as per TB 2.0. I hadn't noticed it before because my default test profile has mailnews.message_display.allow.plugins set to true which hides it, unfortunately reftest uses the default profile...

The consequences are simple: content of TYPE_OBJECT (e.g. plugins - flash etc, object elements) are not allowed to be loaded in Thunderbird (or any APP_TYPE_MAIL window in SeaMonkey) if mailnews.message_display.allow.plugins is set to false.

This is irrespective of if the content is loaded from http/rss or within messages.

Comment 9

[Mark Banner (:standard8)]

Following bug 615675 landing, I took another look at reftests. It appears the original failures noted in this bug are now gone. Whilst there are some other failures, my suspicion is they are mainly builder set up issues, and therefore are probably covered elsewhere if we want to move forward with semi-regularly running reftest & co, that's a decision for elsewhere, so this bug can be closed.