(In reply to James Graham [:jgraham] [Away until 2019-07-08] from comment #3)
the standard assumption is that the no-flag case is just like what a consumer would use
For WebRender the conditions that enable it by default are super complex, involving things like whether you're on a laptop vs desktop, your screen size, graphics card, etc. For this reason we basically never want any test harnesses to fall back to the case where the product "default" behaviour is chosen; we want to make sure WR is always either explicitly enabled or disabled.
I would quite strongly prefer that in our task definitions we actually always supplied either
--no-enable-webrender so that it's obvious that changing product defaults doesn't have any effect there.
As a general principle I agree with this. In this scenario though I felt that making the
--no-enable-webrender explicitly implied by lack of
--enable-webrender would be better because it leaves only two possibilities (providing the flag or not) vs 4 possibilities, two of which (neither flag provided, or both flags provided) are undesirable.
Like I said, I don't have strong objections to your adding this flag, as long as the expected usage is clear, and we retain the behaviour that absence of
--enable-webrender will explicitly force WR off instead of falling back to the "product default" behaviour (which is too complex to be a sane default for anybody).