I’ve been aware of these proposals. Honestly, there’s not a lot of meat in the
performance timeline proposal and one of the editors doesn’t appear to be
actively involved anymore.
IMO, this is implementation detail for describing the data structures used by a
timeline “entry”. I’m not sure how
self-reply. --1.
On 2013-07-11, at 09:56 , Rob Campbell wrote:
> On 2013-05-31, at 15:46 , Boris Zbarsky wrote:
[…]
>> 1) It does not show feedback requests. This may explain why some people
>> are routinely ignoring them….
>
> Good point. I filed:
>
> https://
On 2013-05-31, at 15:46 , Boris Zbarsky wrote:
> On 5/24/13 10:50 AM, Justin Lebar wrote:
>> Consider for example how much better harthur's fileit and dashboard
>> tools [1] [2] are than bugzilla's built-in equivalents.
Wasn't "fileit" integrated into the New Bug page? That search suggestion
d
On 2013-05-29, at 18:58 , Justin Dolske wrote:
> On 5/29/13 3:09 PM, Ehsan Akhgari wrote:
>> Typically when you use the terminal to open an application on Mac, the
>> application is opened in the background.
>
> Mmm, indeed. Someone told me long ago this this was a platform convention,
> but i
On 2013-05-18, at 06:09 , David Rajchenbach-Teller wrote:
> Hi everyone,
>
> As part of the ongoing effort to make (Chrome) Workers useful for
> platform refactorings, we have been working on a lightweight module
> loader for workers (bug 872421). This loader implements a minimal
> versi
On 2013-04-17, at 11:42 , Matt Brubeck wrote:
> On 4/15/2013 11:04 AM, Rob Campbell wrote:
>> On Mac, does mach do the right thing when you rebuild browser, does it also
>> rebuild browser/app so your application bundle gets updated?
> "mach build browser" is
Well this is pretty sweet.
On Mac, does mach do the right thing when you rebuild browser, does it also
rebuild browser/app so your application bundle gets updated?
Thanks for doing this, Matt!
Rob
On 2013-03-16, at 3:48 PM, Matt Brubeck wrote:
> I recently landed a new feature for the "mach"
It's partially usable. I think the biggest issue right now is bug 808588 -
"Cannot debug script files included in a xul file" (and possibly scripts loaded
via loadSubScript). We need to figure out why this is preventing some classes
of script from hitting breakpoints in chrome.
Debugging JSMs t
Filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=806928.
On 2012-10-30, at 03:30 , Jan Honza Odvarko wrote:
> On Oct 29, 8:57 pm, Mats Palmgren wrote:
>> On 10/29/2012 07:47 PM, Jan Honza Odvarko wrote:
>>
>>> Is there any depth limit for HTML elements in a document?
>>
>> Yes, around
Mook also referenced this bug in IRC:
[HTML5] HTML5 parser gives up easily with deeply nested tags
https://bugzilla.mozilla.org/show_bug.cgi?id=512605
On 2012-10-29, at 15:57 , Mats Palmgren wrote:
> On 10/29/2012 07:47 PM, Jan Honza Odvarko wrote:
>> Is there any depth limit for HTML elements
This sounds really familiar. Honza, did you run into this in the past?
In any case, I was able to reproduce this with the attached test-case in your
bug:
http://cl.ly/KWCQ
I asked Sebastian if he'd filed a bug on us yet, after my meeting I'll file it
if he hasn't by then.
On 2012-10-29, at 15
+1.
Flatter directory structures are virtuous. I also shudder at the thought of a
bunch of patches and potential tree redness from scripts that shuffle around
our make files for no reason other than adding extra depth.
In most cases, the location of the tests will dictate what types of tests li
12 matches
Mail list logo
