Re: any concerns with dropping the talos test v8 and using AWFY Octane instead?

> >> It seems like another alternative might be to run Octane in Talos, > >> instead of v8_7. > >> > >> It seems like Talos has two advantages over AWFY (correct me if I'm wrong): > >> > >> 1. Easy for developers to schedule jobs via try (maybe less of a concern > >> with a benchmark like this,

Re: Taking screenshots of single elements (XUL/XULRunner)

In case my OP isn't clear enough. I'm basically looking for the XUL counterpart to WPF's/XAML's RenderTargetBitmap, which enables the developer to render a selected UIElement to a Pixelbuffer and save it as png, with full alpha blending support. ___

Re: Taking screenshots of single elements (XUL/XULRunner)

On Tue, Jan 19, 2016, at 01:39 AM, m.bauermeis...@sto.com wrote: > As part of my work on a prototyping suite I'd like to take screenshots > (preferably retaining the alpha channel) of single UI elements. I'd like > to do so on an onclick event. > > Is there a straightforward way to accomplish

Re: Taking screenshots of single elements (XUL/XULRunner)

Which is also what DevTools does: https://dxr.mozilla.org/mozilla-central/source/devtools/shared/gcli/commands/screenshot.js#260 On Tue, Jan 19, 2016 at 1:03 PM, Andreas Tolfsen wrote: > On 19 January 2016 at 11:22, Ted Mielczarek wrote: > > On Tue, Jan

Re: E10S performance & stability metrics (January 2016 edition)

> Unfortunately, the BHR Telemetry data from both Aurora 43 & Beta 44 > experiments suggests that e10s is jankier than non-e10s. This holds true > for profiles with & without extensions. > > However, we have identified bugs causing inaccuracies in BHR reporting and > we are working to imporve BHR

You can now run specific tasks in an xpcshell test using add_task.only / add_test.only

Hi Folks, I have just recently pushed bug 1192533, which will allow more fine grained debugging in xpcshell tests. I often had the problem that only a single task within a test was failing. Running the test over and over again took longer because all the other tasks had to run. I wished we could

Re: You can now run specific tasks in an xpcshell test using add_task.only / add_test.only

Fwiw, I used to perform a search-replace `add_task` => `/*add_task*/` to deactivate everything, then uncomment individual tasks. Of course, your solution looks cleaner, especially if it can be made to work via mach. Cheers, David On 19/01/16 13:39, Philipp Kewisch wrote: > Hi Folks, > > I

Re: Taking screenshots of single elements (XUL/XULRunner)

Thanks for the pointers. I've decided to try the basics first, rendering the whole window to the canvas. Unfortunately, the result, as of yet, is an empty canvas with a white background. Anything I'm missing here? http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul;

Re: Taking screenshots of single elements (XUL/XULRunner)

You can try getting access to https://dxr.mozilla.org/mozilla-central/source/testing/marionette/capture.js and then that will give you everything you want or you can just "borrow" the code from there. David On 19 January 2016 at 11:22, Ted Mielczarek wrote: > On Tue, Jan

Re: Proposed changes to Talos (performance) alerting

On 2016-01-18 4:42 AM, Nicolas B. Pierron wrote: I agree, this should be the part of the developer to work that out, but the TS Paint benchmark is out of the knowledge base of JS developers. I feel that the problem is reaching developers with a wording known by the developers. So we have a

Re: Proposed changes to Talos (performance) alerting

> > This is just a raw idea, but maybe this would make more sense to provide a > diff of profiles, and show what decreased / increased. At least this would > make these benchmarks less obscure. > Pushing a before/after patch to try with profiling (note the numbers are not useful) can be done

Re: Dominator tree memory analysis now in Nightly

There's actually a bug on file with designs that I'd like to implement for exposing panels better than they currently. (If you look at the mockups, not dissimilar to what Nick's suggesting!) As for whether or not we should always expose the Memory tool

Re: Dominator tree memory analysis now in Nightly

Apologies everyone, Jared pointed out that I didn't actually link to the bug correctly: Bug 1238982 https://bugzilla.mozilla.org/show_bug.cgi?id=1238982 On Fri, Jan 15, 2016 at 7:10 AM, Helen Holmes wrote: > There's actually a bug on file

Re: Dominator tree memory analysis now in Nightly

On 14/01/2016 23:01, Nick Fitzgerald wrote: On Thu, Jan 14, 2016 at 2:49 PM, Jared Wein > wrote: Also, what is the plan for making tools like the Memory view appear in a default install? In other words, without having to go to the

[Firefox Desktop] Issues found: January 11th to January 15th

Hi everyone, Here's the list of new issues found and filed by the Desktop Manual QA team last week, _January 11th - January 15th_ (week 2). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: Dominator tree memory analysis now in Nightly

On Sat, Jan 16, 2016 at 5:41 AM, Philip Chee wrote: > This is great! Is there a way of expanding/collapsing the whole tree? > Thunderbird uses "\" (collapse) and "*" (expand). > ​You can use ALT+click on an arrow to expand a​ whole subtree. However, because after a