Re: Try-based code coverage results

On 7/11/2014 5:59 PM, cdaw...@mozilla.com wrote: Hi Joshua-- I work on the Treeherder dev team. Would you be up for > writing a few bugs against Treeherder on what you found? Here’s a > link to do so: > https://bugzilla.mozilla.org/enter_bug.cgi?product=Tree%20Management I did talk to people

Re: Try-based code coverage results

On Friday, July 11, 2014 3:59:41 PM UTC-7, cda...@mozilla.com wrote: > On Monday, July 7, 2014 4:44:50 PM UTC-7, Joshua Cranmer 🐧 wrote: > > > On 7/7/2014 5:25 PM, Jonathan Griffin wrote: > > > > > > > Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1035464 for those > > > > > > > that w

Re: Try-based code coverage results

On Monday, July 7, 2014 4:44:50 PM UTC-7, Joshua Cranmer 🐧 wrote: > On 7/7/2014 5:25 PM, Jonathan Griffin wrote: > > > Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1035464 for those > > > that would like to follow along. > > > > Perhaps bug 890116 is a better measure of tracking. > >

Intent to ship: the 'box-decoration-break' CSS property

As of 2014-07-08 support for the CSS property 'box-decoration-break' has been turn on by default in Nightly (sorry for being late in announcing that). It's been developed behind the preference "layout.css.box-decoration-break.enabled". The plan is to enable it by default also on Aurora (32) to p

.properties and a single \u

Hi, in .properties foo = some \unicode bar = some \a creates the most icky output. I'd like to get a defined behavior, but it turns out to be hard. Java: - dies with a parsing error on foo, bar is "some a" XPCOM: - returns "some ", as \u is converted to \0 on foo, bar is "some a" Gaia:

Re: How does xpcshell unittest are runned

This is the case on opt builds, but at least on tbpl, debug builds of xpcshell dump error information about why a file failed to load/run, e.g. https://tbpl.mozilla.org/php/getParsedLog.php?id=43053178&tree=Mozilla-Esr24 ~ Gijs On 11/07/2014 09:12, Mike de Boer wrote: Error code 3, for me, a

Re: How does xpcshell unittest are runned

Error code 3, for me, always meant that I made a typo in head.js - or other JS files loaded other than the test file itself - that caused a SyntaxError. It’s unfortunate that there’s no better error reporting during loading and evaluation of JS while loading the harness, so I needed to resort to