Run mochitest-oth-e10s in automation

NEW
Unassigned

Status

Testing
General
--
major
3 years ago
3 years ago

People

(Reporter: Ehsan, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(e10s+, firefox43 affected)

Details

(Reporter)

Description

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

Updated

3 years ago
See Also: → bug 1200912
Um, this is bad. When did we break this?
Severity: normal → blocker
Oh, wait, this is not as bad as I thought. OK. We're just not running it under e10s.
Severity: blocker → major
Summary: Run mochitest-oth in automation → Run mochitest-oth-e10s in automation
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.
(Reporter)

Comment 4

3 years ago
(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!

Updated

3 years ago
Blocks: 984139
tracking-e10s: ? → +
(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.
(Reporter)

Comment 6

3 years ago
(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.
(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.
(Reporter)

Comment 8

3 years ago
(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.
You need to log in before you can comment on or make changes to this bug.