On 11/9/2012 10:12 AM, Kyle Huey wrote:
On Sun, Nov 4, 2012 at 11:53 PM, Mook
wrote:
Ping - was this part ever answered?
Did you see my email on November 1st?
- Kyle
Argh; sorry, Thunderbird screwed up threading there and decided your
message was a sibling. That, and I initially read it
On Sun, Nov 4, 2012 at 11:53 PM, Mook
wrote:
> Ping - was this part ever answered?
Did you see my email on November 1st?
- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Ping - was this part ever answered? I've written (external) things that
depended on BackstagePass being available (due to things like bug
805687); that's definitely importing from the platform.
Of course, I'm not touching B2G/Fennec yet, so I'm okay... but that's
exposed API already ;)
--
M
Right - the linked modules are not jetpack-only code - they're part of
"core" gecko code now, and the plan is to land even more of them, so
we need to keep them working somehow.
Gavin
On 2012-11-02, at 9:33 AM, David Rajchenbach-Teller wrote:
> On 11/2/12 4:42 PM, Kyle Huey wrote:
>> On Thu, No
On 11/2/12 4:42 PM, Kyle Huey wrote:
> On Thu, Nov 1, 2012 at 10:24 AM, Gavin Sharp wrote:
>
>> On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey wrote:
>>> Not if the pref isn't set. If the pref is set I suspect it still returns
>>> an object with the relevant properties, but that object is no longer
On Nov 2, 2012, at 8:42, Kyle Huey wrote:
> On Thu, Nov 1, 2012 at 10:24 AM, Gavin Sharp wrote:
>
>> On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey wrote:
>>> Not if the pref isn't set. If the pref is set I suspect it still returns
>>> an object with the relevant properties, but that object is no
On Thu, Nov 1, 2012 at 10:24 AM, Gavin Sharp wrote:
> On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey wrote:
> > Not if the pref isn't set. If the pref is set I suspect it still returns
> > an object with the relevant properties, but that object is no longer a
> > BackstagePass. I haven't verified
On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey wrote:
> Not if the pref isn't set. If the pref is set I suspect it still returns
> an object with the relevant properties, but that object is no longer a
> BackstagePass. I haven't verified that though.
Will that break
http://mxr.mozilla.org/mozilla-c
On Tue, Oct 30, 2012 at 8:02 PM, Blair McBride wrote:
> Does this break the usage of the BackstagePass object? (the thing that
> Cu.import() returns).
>
Not if the pref isn't set. If the pref is set I suspect it still returns
an object with the relevant properties, but that object is no longer
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
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
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
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
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,
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
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
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
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
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
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-
> 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
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
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
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
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
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"
26 matches
Mail list logo
