Re: [dev-servo] loading web fonts synchronously during automation

Seems generally doable, but probably more than I want to chew right now. I'll get an issue filed though. Does anyone object to landing the synchronous font loading as a stopgap to get better reftest coverage until we make the font loading logic smarter? On Wed, Nov 4, 2015 at 8:14 PM, Bobby Holle

Re: [dev-servo] loading web fonts synchronously during automation

That's a great point - I'll take a look to see how doable it is. On Wed, Nov 4, 2015 at 7:28 PM, L. David Baron wrote: > On Wednesday 2015-11-04 19:16 -0800, Bobby Holley wrote: > > Right now, every wpt test includes a stylesheet with an @font-face rule > to > > make the 'ahem' font available to

Re: [dev-servo] loading web fonts synchronously during automation

On Wednesday 2015-11-04 19:16 -0800, Bobby Holley wrote: > Right now, every wpt test includes a stylesheet with an @font-face rule to > make the 'ahem' font available to tests. Since font loading triggers a > document-wide reflow, we end up with a non-deterministic network-driven > reflow in each a

[dev-servo] loading web fonts synchronously during automation

Right now, every wpt test includes a stylesheet with an @font-face rule to make the 'ahem' font available to tests. Since font loading triggers a document-wide reflow, we end up with a non-deterministic network-driven reflow in each and every test, which makes it harder to test layout optimizations

Re: [dev-servo] Handling cases where the spec is inefficient and not followed by anyone

Oh, yeah, in that case we should just mimic the other browsers and file bugs. -Manish Goregaokar ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Thu, Nov 5, 2015 at 12:44 AM, James Graham wrote: > On 04/11/15 11:41, Robert O'Callahan wrote: > >> The media tests are better than I thought --- I found more. They don't >> test >> the variety of problematic media files that our mochitests do, but maybe >> that's not in scope? Should we be w

Re: [dev-servo] Handling cases where the spec is inefficient and not followed by anyone

On 11/4/15 12:09 PM, Manish Goregaokar wrote: I'd prefer to avoid diverging from the spec wherever possible -- even if other browsers disagree (with the spec and with each other) I think Ms2ger was talking about cases in which the spec disagrees with all browsers, who agree with each other.

Re: [dev-servo] Handling cases where the spec is inefficient and not followed by anyone

On Wed, Nov 4, 2015 at 9:17 PM, Ms2ger wrote: > I'm not sure why you scoped this to inefficient spec algorithms Because inefficient or complexity-inducing specs cause problems, the rest, less so. If the spec isn't consistently implemented across the board, but implementing the spec is low-effo

Re: [dev-servo] Handling cases where the spec is inefficient and not followed by anyone

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2015 08:21 PM, Manish Goregaokar wrote: > We've recently had two > cases where: > > - The spec suggests something which if implemented correctly, would >

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On 04/11/15 11:41, Robert O'Callahan wrote: Sure. https://github.com/w3c/web-platform-tests/issues/2304 Thanks! The media tests are better than I thought --- I found more. They don't test the variety of problematic media files that our mochitests do, but maybe that's not in scope? Should we

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Thu, Nov 5, 2015 at 12:17 AM, James Graham wrote: > On 04/11/15 11:12, Robert O'Callahan wrote: > >> Well sure, I agree that taking mochitests as the input to a test-writing >>> effort is a good idea. I see this as being very different to blindly >>> shimming mochitests into the wpt harness. H

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On 04/11/15 11:12, Robert O'Callahan wrote: Well sure, I agree that taking mochitests as the input to a test-writing effort is a good idea. I see this as being very different to blindly shimming mochitests into the wpt harness. Having said that, however, I don't think people have complained a lot

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Wed, Nov 4, 2015 at 11:50 PM, James Graham wrote: > On 04/11/15 10:24, Robert O'Callahan wrote: > >> On Wed, Nov 4, 2015 at 5:14 PM, James Graham >> wrote: >> >> On 03/11/15 22:08, Robert O'Callahan wrote: >>> >>> Why not create a Mochitest compatibility layer over testharness.js so >>>

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On 04/11/15 10:24, Robert O'Callahan wrote: On Wed, Nov 4, 2015 at 5:14 PM, James Graham wrote: On 03/11/15 22:08, Robert O'Callahan wrote: Why not create a Mochitest compatibility layer over testharness.js so that tests that only use SimpleTest.waitForExplicitFinish(), SimpleTest.finish(),

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Wed, Nov 4, 2015 at 5:14 PM, James Graham wrote: > On 03/11/15 22:08, Robert O'Callahan wrote: > > Why not create a Mochitest compatibility layer over testharness.js so >> that tests that only use SimpleTest.waitForExplicitFinish(), >> SimpleTest.finish(), is(), todo() and ok() can run on Serv