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

[jmaher]

> >> 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, where I suspect results are more
> >> reproducible locally?)
> >
> > I believe there was talk of adding try support for AWFY (there already is 
> > for AWSY). Of course that's not actually done yet, I just want to point out 
> > it's not particularly hard and AWSY's version could be adapted rather 
> > easily.
> >

Running Octane in Talos would be useful, but we would be duplicating efforts.  
While that is not a bad thing, will we get value from it.  We do get value in 
self serving support with try and tools like mozci for backfilling and 
retriggering.  The issue in the bug also points out that the developers who 
care about Octane use AWFY and already detect these regressions before talos 
does (or at least a sheriff finds it and files a bug).  This specific topic of 
upgrading V8 to Octane for Talos should be discussed in bug 1174671.


> Talos already runs on non-virtualized hardware. I don't see any inherent 
> reason we couldn't rework AWSY as a Talos test. In general it feels to 
> me like we should be running performance tests on relops-supported 
> infrastructure where possible, as opposed to adhoc systems.

I would agree that the more we can run on managed systems the better.  While 
all Talos jobs are run on non-virtualized hardware today, we do run on a shared 
pool of hardware with the unittests.  One difference between AWFY and Talos is 
that the numbers are so much more stable, even in the browser version (AWFY 
runs a js shell as well as a browser).  I believe this is attributed to the 
type of hardware, the environment, or the fact that a specific test is run on a 
specific machine.

> > In general it would be great if we could consolidate the various perf tests 
> > (AWFY, AWSY, Talos, Raptor, etc) under one umbrella (at least from an end 
> > user perspective). So you could go to trychooser and choose a "Perf" option 
> > that would have various subsets like: "JS Engine", "Memory Usage", "Layout 
> > Latency", "Mobile Launch Time", etc.
> >

This is a worthwhile goal- Simplifying the interface to the tools over the next 
few quarters to allow for common sheriffing, and self serving will make big 
strides.

> 
> 1. It assumes that all test machines of a particular class will be 
> uniform, at least per test. For example, Autophone tracks the 
> performance of something like 9 different Android devices seperately 
> (see: http://phonedash.mozilla.org/) -- that's not something Perfherder 
> was designed to do.

As mentioned earlier in this comment AWFY runs the same test on the same 
machine- the numbers are more reliable, but there is no further evidence that 
is the cause of the noise in Talos, I suspect it is a factor.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[M . Bauermeister]

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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ted Mielczarek]

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 this? Possibly with XPCOM or
> js-ctypes?

You can use the drawWindow method of CanvasRenderingContext2D:
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawWindow

You just need to create a canvas element, call getContext('2d') on it,
and then calculate the offset of the element you want to screenshot.

-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Patrick Brosset]

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 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 this? Possibly with XPCOM
> or
> >> js-ctypes?
> >
> > You can use the drawWindow method of CanvasRenderingContext2D:
> >
> https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawWindow
> >
> > You just need to create a canvas element, call getContext('2d') on it,
> > and then calculate the offset of the element you want to screenshot.
>
> What Ted explains here is what we do for Marionette.  You can probably
> draw some inspiration from
>
> https://dxr.mozilla.org/mozilla-central/source/testing/marionette/capture.js#17
> .
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Vladan D]

> 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 as well as other Telemetry performance
> measurements. We have even built an extension to visualize BHR's jank
> detection: https://github.com/chutten/statuser
>
> In general, as we evaluate e10s performance using A/B experiments, we also
> validate and improve the performance probes in parallel.

I have been told this part of my post is misleading, so I'll go into more 
detail about what we know and don't know about the reliability of the BHR 
responsiveness measurement and consequently e10s's performance.

1) We know BHR over-reported jank for e10s Firefox during both A/B experiments. 
This was fixed & uplifted in bug 1234618, but the uplifts didn't make it into 
either of the Aurora 43 & Beta 44 experiments. This means that the BHR 
experiment analyses linked above are not reliable. The upcoming Beta 45 A/B 
experiment will have the issue fixed.

2) Bill McCloskey looked at BHR e10s vs non-e10s performance on the general 
Aurora 45 population (not as part of an A/B experiment) and found that in these 
(not randomly selected) e10s & non-e10s populations, e10s is more responsive.
Bill's analysis: http://people.mozilla.org/~wmccloskey/aurora-analysis.html

3) We know that up to now, BHR did not report jank from the e10s child process 
at all (bug 1228437). This would have caused under-reporting of e10s jank 
during the A/B experiments as well as in billm's Aurora analysis. This is now 
fixed in bug 1228437 and pending uplift.

4) BHR uses "pseudostacks" to report the sources of hangs. The C++ psuedostack 
is lacking in coverage, reducing the usefulness of the collected stacks. This 
is now addressed in bug 1224374 and pending uplift.

5) There were additional issues with the most recent Beta 44 A/B experiment 
(e.g. bug 1236754) which reduced the quality of the collected data.

To summarize, validating & fixing BHR is an ongoing effort, and we don't have a 
basis for determining whether e10s performance is better or worse than non-e10s 
performance based on the BHR numbers yet. I am very optimistic about the 
quality of BHR data we will obtain from the upcoming Beta 45 A/B experiment.

P.S. Note that we have much higher confidence in the e10s Telemetry stability 
numbers. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Philipp Kewisch]

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 use .only() and .skip() as you may know from mocha tests.

Well, now you can! It currently requires editing the file instead of
running via a mach parameter, but since you are fixing an issue you'll
be editing the file anyway.

Before:

add_task(function* my_test() {
// the failing task.
// ...
});

add_test(function my_async_test() {
// a working test.
// ...
run_next_test();
});

After:

add_task.only(function* my_test() {
   // the failing task, ready to debug
});

add_test.skip(function my_async_test() {
// a working test.
// ...
run_next_test();
});

Then run the test as usual, no extra parameters.

Don't forget to remove the .only/.skip when you are done. With a little
extra effort this could be changed to pass the task name via mach, I've
made a suggestion how to do this in the bug comment 3.

Philipp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[David Rajchenbach-Teller]

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 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 use .only() and .skip() as you may know from mocha tests.
> 
> Well, now you can! It currently requires editing the file instead of
> running via a mach parameter, but since you are fixing an issue you'll
> be editing the file anyway.
> 
> Before:
> 
> add_task(function* my_test() {
> // the failing task.
> // ...
> });
> 
> add_test(function my_async_test() {
> // a working test.
> // ...
> run_next_test();
> });
> 
> After:
> 
> add_task.only(function* my_test() {
>// the failing task, ready to debug
> });
> 
> add_test.skip(function my_async_test() {
> // a working test.
> // ...
> run_next_test();
> });
> 
> Then run the test as usual, no extra parameters.
> 
> Don't forget to remove the .only/.skip when you are done. With a little
> extra effort this could be changed to pass the task name via mach, I've
> made a suggestion how to do this in the bug comment 3.
> 
> Philipp
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[M . Bauermeister]

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; 
xmlns:html="http://www.w3.org/1999/xhtml; id="window">

Test






var canvas = document.getElementById("canvas");
var ctx = canvas.getContext("2d");
ctx.drawWindow(window, 0, 0, 1024, 768, "rgba(255,255,255,1)");

 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[David Burns]

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 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 this? Possibly with XPCOM or
> > js-ctypes?
>
> You can use the drawWindow method of CanvasRenderingContext2D:
>
> https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawWindow
>
> You just need to create a canvas element, call getContext('2d') on it,
> and then calculate the offset of the element you want to screenshot.
>
> -Ted
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed changes to Talos (performance) alerting

[William Lachance]

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 wiki page which describes each Talos test in detail, we 
link to these in all perf bugs, but it can be useful reading on its own. 
For example, ts_paint is described here:


https://wiki.mozilla.org/Buildbot/Talos/Tests#ts_paint

I'm sure some of the test descriptions could use some improvements, feel 
free to ask on #perf if anything's unclear.



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.


As Joel mentioned, it's pretty easy to schedule profiling runs for talos 
using trychooser. Scheduling a profiling run as part of the 
regression-filing process is something we could consider doing, if 
there's a broad consensus it would be useful (I'm always wary of putting 
extra load on the machines for something that would be only useful in 
10%, say, of cases).


Will
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed changes to Talos (performance) alerting

[jmaher]

> 
> 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 and there is a simple checkbox on trychooser.  I am not 
familiar with any diff tools and would wonder how much noise would show up.  It 
does seem worthwhile.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Helen Holmes]

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 on a clean
install, I think we're hoping to drive the answers to those questions with
better data. I believe Jordan created an etherpad
 that probably
needs some love when it comes to thinking about what telemetry probes we
want to add and who owns what data in devtools. As far as I currently know:
the memory is not on by default in release and it might be in both dev
edition and nightly (Jeff would know for certain as resident Telemetry
King).

On Thu, Jan 14, 2016 at 6:12 PM, Gijs Kruitbosch 
wrote:

> 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 Settings. I
>> worry that users may not know to click on the Settings and just think that
>> other browsers offer more tools than we do.
>>
>
> ​This is a good conversation to have, but I don't have any good answers.
> We have a lot of panels in the devtools, many of which are fairly niche,
> and it isn't clear how to simultaneously give them visibility and not
> overwhelm users.
>
> Console, debugger, performance: these panels are ​a clear "always show" to
> me. The web audio tool is very niche and so I don't think it would make
> sense to show it by default. The memory tool falls in between in my mind.
> I'm open to suggestions!
>
> We could add a [...] or similar button at the end with a dropdown for the
> other tools? With some TBD as to whether that enables them permanently or
> just for that site and/or how to toggle that.
> (pulling in Helen because I think she might have better ideas :-) )
>
> ~ Gijs
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Helen Holmes]

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 
> 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 on a clean
> install, I think we're hoping to drive the answers to those questions with
> better data. I believe Jordan created an etherpad
>  that probably
> needs some love when it comes to thinking about what telemetry probes we
> want to add and who owns what data in devtools. As far as I currently know:
> the memory is not on by default in release and it might be in both dev
> edition and nightly (Jeff would know for certain as resident Telemetry
> King).
>
> On Thu, Jan 14, 2016 at 6:12 PM, Gijs Kruitbosch  > wrote:
>
>> 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 Settings. I
>>> worry that users may not know to click on the Settings and just think that
>>> other browsers offer more tools than we do.
>>>
>>
>> ​This is a good conversation to have, but I don't have any good answers.
>> We have a lot of panels in the devtools, many of which are fairly niche,
>> and it isn't clear how to simultaneously give them visibility and not
>> overwhelm users.
>>
>> Console, debugger, performance: these panels are ​a clear "always show"
>> to me. The web audio tool is very niche and so I don't think it would make
>> sense to show it by default. The memory tool falls in between in my mind.
>> I'm open to suggestions!
>>
>> We could add a [...] or similar button at the end with a dropdown for the
>> other tools? With some TBD as to whether that enables them permanently or
>> just for that site and/or how to toggle that.
>> (pulling in Helen because I think she might have better ideas :-) )
>>
>> ~ Gijs
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Gijs Kruitbosch]

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 Settings. I worry that users may not know to click on the
Settings and just think that other browsers offer more tools than
we do.


​This is a good conversation to have, but I don't have any good 
answers. We have a lot of panels in the devtools, many of which are 
fairly niche, and it isn't clear how to simultaneously give them 
visibility and not overwhelm users.


Console, debugger, performance: these panels are ​a clear "always 
show" to me. The web audio tool is very niche and so I don't think it 
would make sense to show it by default. The memory tool falls in 
between in my mind. I'm open to suggestions!
We could add a [...] or similar button at the end with a dropdown for 
the other tools? With some TBD as to whether that enables them 
permanently or just for that site and/or how to toggle that.

(pulling in Helen because I think she might have better ideas :-) )

~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrei Vaida]

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:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus


*RELEASE CHANNEL*
none

*BETA CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1238949 
[Ubuntu] Hello panel can be resized while on Loop Getting Started URL
NEW 
TBD NOBODY
NORMAL  1238932 
Unable to upload picture to Firefox Accounts from firstrun
NEW 
TBD NOBODY
NORMAL  1238940 
Wrong link redirect when clicking Email Preferences from Firefox 
Accounts
NEW 
TBD NOBODY
NORMAL  1238960 
Firefox Accounts preference pane won't close when Back button is pressed
NEW 
NO  NOBODY
NORMAL  1238961 
Browser becomes unresponsive when stressing the Firefox Accounts page
NEW 
TBD NOBODY
NORMAL  1238962 
The FXA settings are overlapping the Add account picture screen
NEW 
YES  NOBODY
NORMAL  1238955 
The light themes are not synced
NEW 
TBD NOBODY
NORMAL  1239662 
Location bar is not updated when deleting all visited websites entries
NEW 
NO  NOBODY
NORMAL  1239663 
Location bar is not updated when deleting search suggestion entries
NEW 
NO  NOBODY
NORMAL  1240027 
	No phishing/malware warnings displayed on the test page after receiving 
the first database update

NEW 
NO  NOBODY


/*Please note* that several //potentially new bugs 
//were 
also found during 44.0b8 Hello Smoke Testing, but they were not yet 
filed in Bugzilla as they're pending assessment from Mark Banner./



*AURORA CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1238522 
Intermittently, the speech synthesis doesn't start after changing the 
Pitch
NEW 
NO  Makoto Kato 
NORMAL  1238538 
Pause/Resume speech does not work on Linux via Speech Dispatcher
NEW 
NO  NOBODY
NORMAL  1238531 
[MAC] “Sign in to Sync” text is written with black using Dev Edition 
theme
NEW 
NO  NOBODY
NORMAL  1238566 
Synced Tabs signed out state is not visually centered
ASSI
NO  Mark Hammond 
NORMAL  1238866 
	[Ubuntu] "Add search engine" in search panel has white background with 
GTK3 and dark theme

NEW 
YES  NOBODY
NORMAL  1238871 
Tabs from a disconnected device are still displayed in Synced Tabs list
REOP
NO  NOBODY



*NIGHTLY CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
CRITICAL1239968 
[Ubuntu] crash in libgdk-x11-2.0.so.0.2400.10@0x72546
NEW 
NO  NOBODY
NORMAL  1238924 
	TP shield icon still displayed in the second browser window after the 
TP was set to OFF in the first window

NEW 
NO  NOBODY
NORMAL  1238969 
	Exceptions dialog updates live when a site is added to the list, but 
doesn't update when a site is removed

NEW 
NO  NOBODY
NORMAL  1238970 
	Make the "Save changes" button available only if there were made any 
changes

NEW 
NO  NOBODY
NORMAL  1239688 
Exceptions set in normal windows don't apply to private windows
NEW 
NO  NOBODY
NORMAL  1240045 
[Dell XPS 12] Facebook tooltip is displayed behind Settings button
NEW 
YES  NOBODY



*ESR CHANNEL*
none


Regards,
Andrei.
Andrei Vaida| QC Team Lead

SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email: andrei.va...@softvision.ro 

Re: Dominator tree memory analysis now in Nightly

[Nick Fitzgerald]

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 certain depth we start incrementally loading sub-trees,
those incrementally loaded subtrees will not be auto-expanded. In general,
the dominator trees are too large to eagerly display in the UI; there is an
item in the tree for every node in the heap graph that we snapshot'd.



>
> Nitpick: The columns don't appear to be resizeable.
>
>
That is a pretty unfortunate screenshot. ​We have a bug in flight to ensure
that the columns are wide enough​:
https://bugzilla.mozilla.org/show_bug.cgi?id=1224201

If we can always ensure that the minimum cell size in the table is large
enough to display the number contained within, then I'm not convinced we
need resizing. Perhaps we can take this discussion to that bug, or a new
one?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform