OK, that all makes sense. So for the first iteration of this, I'll go ahead
and target an honest to ${DEITY} full pageload. If any one knows of any way
to do this headless, I'd love to hear it, otherwise we're going to have to
go ahead and use a modified Talos pageloader extension to do what we want
(which requires some way to display the browser, which adds new headaches
to the infrastructure).Also, since we're doing full page loads, we can have any of the data points from the navigation timing API in our results. What ones do we want to have? I'm thinking, at a minimum, the "global picture" (loadEventEnd - navigationStart), but we can break it down further (for reference: available points, according to the spec, are at http://www.w3.org/TR/navigation-timing/#processing-model - if we don't implement all of those points, then obviously the unimplemented ones aren't available to us). Thoughts? On Tue, Dec 4, 2012 at 10:29 AM, Jason Duell <[email protected]> wrote: > I have everything ready client-side to do this kind of test (including a >> script to take a pageload recorded with web-page-replay and figure out >> what >> resources need to be loaded when). >> > > I agree with Patrick and Honza that the most important priority is > emulating real firefox behavior. But if you're really got the dumb-script > approach working already, that would be a useful data point to have too. > It could be useful to have that to help us analyze if a regression is > purely within necko or not. > > Jason > > ______________________________**_________________ > dev-tech-network mailing list > dev-tech-network@lists.**mozilla.org <[email protected]> > https://lists.mozilla.org/**listinfo/dev-tech-network<https://lists.mozilla.org/listinfo/dev-tech-network> > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
