1200908 - Run mochitest-oth-e10s in automation

Status: NEW

(Testing :: General, defect)

Description

[(no longer active)]

It seems like currently we don't run this suite anywhere in the automation.  This has let bug 1200906 and perhaps others slip in...

Comment 1

[(not currently active) Ted Mielczarek]

Um, this is bad. When did we break this?

Comment 2

[(not currently active) Ted Mielczarek]

Oh, wait, this is not as bad as I thought. OK. We're just not running it under e10s.

Comment 3

[Jonathan Griffin (:jgriffin)]

This is really just two suites...mochitest-chrome and mochitest-a11y.  At one point in the past I was told we don't need mochitest-chrome on e10s, since it's all parent process stuff anyway.  Is that still true?

For mochitest-a11y, that suite was very badly broken on e10s last time I checked it on try, back in June.

The last mochitest-oth runs on holly (from July) are very broken as well.  This will need to be fixed before we can turn it on.

Comment 4

[(no longer active)]

(In reply to Jonathan Griffin (:jgriffin) from comment #3)
> This is really just two suites...mochitest-chrome and mochitest-a11y.  At
> one point in the past I was told we don't need mochitest-chrome on e10s,
> since it's all parent process stuff anyway.  Is that still true?

That has *never* been true!  I'm surprised to hear someone thinks that.

> For mochitest-a11y, that suite was very badly broken on e10s last time I
> checked it on try, back in June.

That's understandable.

> The last mochitest-oth runs on holly (from July) are very broken as well. 
> This will need to be fixed before we can turn it on.

Of course!

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(In reply to Ehsan Akhgari (don't ask for review please) from comment #4)
> That has *never* been true!  I'm surprised to hear someone thinks that.

Most mochitest-chrome tests (about 70% by my count) are .xul files. We don't support XUL in the content process.

I think the hardest part about supporting these tests will be figuring out whether a given test makes sense to run in e10s. Not even all of the .html files make sense. Some of them do things like creating remote iframes or browser elements to test the message manager or CPOWs, which won't work in a content process.

Comment 6

[(no longer active)]

(In reply to Bill McCloskey (:billm) from comment #5)
> (In reply to Ehsan Akhgari (don't ask for review please) from comment #4)
> > That has *never* been true!  I'm surprised to hear someone thinks that.
> 
> Most mochitest-chrome tests (about 70% by my count) are .xul files. We don't
> support XUL in the content process.

Do we have the option of loading these files in the parent process (like we do with about:preferences, for example?)

> I think the hardest part about supporting these tests will be figuring out
> whether a given test makes sense to run in e10s. Not even all of the .html
> files make sense. Some of them do things like creating remote iframes or
> browser elements to test the message manager or CPOWs, which won't work in a
> content process.

Yes, that's true.

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(In reply to Ehsan Akhgari (don't ask for review please) from comment #6)
> Do we have the option of loading these files in the parent process (like we
> do with about:preferences, for example?)

There are some flags, remoteenabled and remoterequired, that you can use in the chrome manifest. I think you could do something there, but I'm not sure.

However, I'm not sure what the point would be of running these tests in "e10s mode" if they're run in the main process. It's no different than what we do now.

Comment 8

[(no longer active)]

(In reply to Bill McCloskey (:billm) from comment #7)
> However, I'm not sure what the point would be of running these tests in
> "e10s mode" if they're run in the main process. It's no different than what
> we do now.

The point would be to run the non-XUL tests in e10s mode proper, and just deal with the XUL ones somehow.