Re: Changes to JS components/JSMs

2012-10-30 Thread Blair McBride
Does this break the usage of the BackstagePass object? (the thing that Cu.import() returns). We rely on that for various testing. Looking at MXR, it looks like the following test areas would be affected: * Add-ons Manager * Sync * Social API (toolkit) * Desktop browser The Add-ons Manager is

Re: Changes to JS components/JSMs

2012-10-30 Thread Alex Keybl
Yeah, my take is that at this point the desire to improve B2G performance (comment 61) >> the risk of subtle breakage, especially given the number of people with eyes on B2G v1 ahead of release. If anybody's got specific areas that we can QA on the phone, please do comment in the bug and we can

Re: Changes to JS components/JSMs

2012-10-30 Thread Dave Townsend
On 10/30/12 14:29, Dave Townsend wrote: On 10/30/12 14:20, Kartikaya Gupta wrote: On 12-10-30 16:31 , Dave Townsend wrote: In case people missed this part specifically, I just want to point out that the change in bug 798491 are targeted for FF18 (Aurora). See comment 75 for philikon's early ris

Re: Changes to JS components/JSMs

2012-10-30 Thread Dave Townsend
On 10/30/12 14:20, Kartikaya Gupta wrote: On 12-10-30 16:31 , Dave Townsend wrote: In case people missed this part specifically, I just want to point out that the change in bug 798491 are targeted for FF18 (Aurora). See comment 75 for philikon's early risk evaluation. From our read of the bug, a

Re: Changes to JS components/JSMs

2012-10-30 Thread Kartikaya Gupta
On 12-10-30 16:31 , Dave Townsend wrote: In case people missed this part specifically, I just want to point out that the change in bug 798491 are targeted for FF18 (Aurora). See comment 75 for philikon's early risk evaluation. From our read of the bug, although this represents major code change,

Re: Proposal for reorganizing test directories

2012-10-30 Thread Karl Tomlinson
Henrik Skupin writes: > differences like 'mochitest' vs. 'mochitests'. The right usage would be > 'mochitest' and it would apply to the other frameworks too. It would be useful to have different names to distinguish between tests and implementation for the tests. I don't know whether that is an

Snappy Meeting, Thurs Nov 1, 11am PT

2012-10-30 Thread Lawrence Mandel
The Snappy meeting is held bi-weekly to discuss issues with Firefox responsiveness and the various responsiveness initiatives that are underway. This week is a Snappy meeting ON week. Please add your items and status to the agenda before the call. https://etherpad.mozilla.org/snappy Dial-in: co

Re: Changes to JS components/JSMs

2012-10-30 Thread Steve Fink
On 10/30/2012 09:11 AM, Kyle Huey wrote: tl;dr: Code in Gecko must now set "magic" properties (such as EXPORTED_SYMBOLS, the symbols themselves, and NSGetFactory) on the 'this' object instead of implicitly on the global via 'var', 'let', 'function', 'const', etc Is the intent to revert these ch

Re: Changes to JS components/JSMs

2012-10-30 Thread Justin Lebar
On Tue, Oct 30, 2012 at 4:31 PM, Dave Townsend wrote: > This plan really worries me. [...] I'm worried that we'll just break the > platform b2g runs on in subtle ways that we might not notice before shipping. > It's pretty concerning to have a fundamental change to how components and > modules are

Re: Changes to JS components/JSMs

2012-10-30 Thread Dave Townsend
On 10/30/12 12:08, Alex Keybl wrote: We have explored various techniques to lower the overhead of a compartment, but unfortunately those fixes that would help at all are either too risky for or cannot be completed in time for Gecko 18. We have decided instead to consolidate all JSMs and JS compo

Re: Changes to JS components/JSMs

2012-10-30 Thread Dave Townsend
On 10/30/12 13:18, Philipp von Weitershausen wrote: On Tue, Oct 30, 2012 at 12:56 PM, Joshua Cranmer wrote: Now, maybe Fennec might want to flip this pref as well (it would make a lot of sense IMHO) in which case we might want to re-evaluate how much this would affect Fennec add-ons (IIRC they'r

Re: Changes to JS components/JSMs

2012-10-30 Thread Philipp von Weitershausen
On Tue, Oct 30, 2012 at 12:56 PM, Joshua Cranmer wrote: > On 10/30/2012 12:53 PM, Kyle Huey wrote: >> >> And just to be extra clear, this doesn't affect addons at all. You can >> sleep easy tonight. >> > > Seeing as how addons can create their own JSMs, how does this not affect > addons? Because

Re: Changes to JS components/JSMs

2012-10-30 Thread Joshua Cranmer
On 10/30/2012 12:53 PM, Kyle Huey wrote: And just to be extra clear, this doesn't affect addons at all. You can sleep easy tonight. Seeing as how addons can create their own JSMs, how does this not affect addons? ___ dev-platform mailing list dev-

Re: New backout policy for Ts regressions on mozilla-inbound

2012-10-30 Thread Ehsan Akhgari
I have documented this here: < https://developer.mozilla.org/en-US/docs/Developer_Guide/Committing_Rules_and_Responsibilities#Dealing_with_performance_regressions > -- Ehsan On Thu, Oct 18, 2012 at 2:05 PM, Ehsan Akhgari wrote: > Hi everyone, > > As part of our effort

Re: Changes to JS components/JSMs

2012-10-30 Thread Alex Keybl
> We have explored various > techniques to lower the overhead of a compartment, but unfortunately those > fixes that would help at all are either too risky for or cannot be > completed in time for Gecko 18. We have decided instead to consolidate all > JSMs and JS components into a single compartme

Tree Closure for hg.m.o disk switchover. Saturday 03nov2012, 9:30am-4:00pm PT

2012-10-30 Thread John O'Duinn
We will have a scheduled maintenance window Saturday morning, Nov 3rd from 9.30am to 4pm PDT. Any access to Hg repositories will be completely down while we migrate data. All trees will be closed during this period and attempts to commit or update will be denied. * bug 805851: hg.mozilla.org da

Re: Changes to JS components/JSMs

2012-10-30 Thread Andrew McCreight
Kyle has already done that. Just check out the 655k patch in bug 798491. Andrew - Original Message - > Are the existing JS modules going to be rewritten whole-sale? Is > there > a bug tracking this? > > Thanks! > Ehsan > ___ > dev-platform ma

Re: Changes to JS components/JSMs

2012-10-30 Thread Kyle Huey
On Tue, Oct 30, 2012 at 10:57 AM, Ehsan Akhgari wrote: > Are the existing JS modules going to be rewritten whole-sale? Is there a > bug tracking this? > The patch in Bug 798491 (I thought I mentioned the bug # originally) does this. - Kyle ___ dev-pla

Re: Changes to JS components/JSMs

2012-10-30 Thread Ehsan Akhgari
Are the existing JS modules going to be rewritten whole-sale? Is there a bug tracking this? Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to JS components/JSMs

2012-10-30 Thread Kyle Huey
And just to be extra clear, this doesn't affect addons at all. You can sleep easy tonight. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to JS components/JSMs

2012-10-30 Thread Gregory Szorc
On 10/30/12 9:11 AM, Kyle Huey wrote: tl;dr: Code in Gecko must now set "magic" properties (such as EXPORTED_SYMBOLS, the symbols themselves, and NSGetFactory) on the 'this' object instead of implicitly on the global via 'var', 'let', 'function', 'const', etc So: const EXPORTED_SYMBOLS = ["Foo"

Changes to JS components/JSMs

2012-10-30 Thread Kyle Huey
(There's a tl;dr at the bottom if you don't want to read the whole thing). Hello all, For B2G we have found the memory overhead of a compartment for each JSM/JS component to be too high for the device. We have explored various techniques to lower the overhead of a compartment, but unfortunately

Re: Coding style change proposal: #pragma once

2012-10-30 Thread Rafael Ávila de Espíndola
Well, in that case I think we can't really do much about this. So, I guess this proposal is canned. I guess we could normalize how we include our own headers, but yes, it does make the proposal quiet a bit harder. Ehsan Cheers, Rafael ___ dev-

Re: Coding style change proposal: #pragma once

2012-10-30 Thread Ehsan Akhgari
On 2012-10-30 2:23 AM, Mike Hommey wrote: It's not a problem of include paths being absolute or not, it's a problem of files of identical content but with different inode being included. A typical case would be: Foo.cpp: #include "Bar.h" #include "mozilla/Foo.h" Bar.h: #include "Foo.h" with Fo

Re: HTML depth limit?

2012-10-30 Thread Marcio Galli
I want to pitch a related thread I stumbled about a year ago — https://bugzilla.mozilla.org/show_bug.cgi?id=485941 Stack overflow using overly-deep XML tree (DoS). I was concerned about JS generating deep nodes which still crashes my recent Firefox — silently, no questions asked. This seems to b

Re: Proposal for reorganizing test directories

2012-10-30 Thread Henrik Skupin
Henrik Skupin wrote on 10/25/12 9:48 AM: > With this post we want to get feedback from module owners and how they > feel with such a reorganization of the tests. If we agree all on it I > would like to go ahead and submit patches in smaller chunks most likely > on a per module basis. I know that w

Re: HTML depth limit?

2012-10-30 Thread Rob Campbell
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

Re: HTML depth limit?

2012-10-30 Thread Jan Honza Odvarko
On Oct 29, 8:07 pm, Rob Campbell wrote: > This sounds really familiar. Honza, did you run into this in the past? No, I haven't noticed that (but obviously the problem has been there for some time) > In any case, I was able to reproduce this with the attached test-case in your > bug: > http://cl

Re: HTML depth limit?

2012-10-30 Thread Jan Honza Odvarko
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 200 or so. > > http://dxr.mozilla.org/search.cgi?tree=mozilla-central&string=MAX_REF... OK, I see. Is there any recommended