On 9/20/2013 9:06 AM, Benjamin Smedberg wrote:
So I would like to propose that we link the JS libraries statically
into libxul and stop exporting JSAPI symbols entirely. This will
effectively prevent extensions from using it.
This has been checked in for Firefox 27 in bug 920731, in the followin
On 9/23/13 8:20 PM, Benjamin Smedberg wrote:
On 9/23/2013 8:45 AM, Philipp Kewisch wrote:
Initially it seems it would be easy to replace calDateTime with a JS
component and I had started to do this, but unfortunately calDateTime
is instanciated directly (via constructor, not via xpcom) in a fe
On 2013-09-21 11:18 PM, xunxun wrote:
于 2013/9/20 星期五 22:02, Benjamin Smedberg 写道:
On 9/20/2013 9:23 AM, Mike Hommey wrote:
We're already statically linking js libraries info libxul. Except on
windows, but that's work in progress in bug 915735
I am primarily worried about doing this on Windows
On 9/23/2013 8:45 AM, Philipp Kewisch wrote:
Initially it seems it would be easy to replace calDateTime with a JS
component and I had started to do this, but unfortunately calDateTime
is instanciated directly (via constructor, not via xpcom) in a few
locations in our C code, so replacing onl
On 9/23/13 2:34 PM, Benjamin Smedberg wrote:
On 9/20/2013 3:12 PM, Philipp Kewisch wrote:
We are not quite ready to get rid of the libical backend right now, so
removing these functions without replacement will cause some
complications for Lightning.
Not knowing this code well, it seems that t
On 9/20/2013 3:12 PM, Philipp Kewisch wrote:
What about JS_NewDateObject, JS_NewDateObjectMsec, JS_ObjectIsDate,
js_DateIsValid? Most of these are in jsapi.h, and we need it in
Lightning for this code:
http://mxr.mozilla.org/comm-central/source/calendar/base/backend/libical/calDateTime.cpp#5
于 2013/9/20 星期五 22:02, Benjamin Smedberg 写道:
On 9/20/2013 9:23 AM, Mike Hommey wrote:
We're already statically linking js libraries info libxul. Except on
windows, but that's work in progress in bug 915735
I am primarily worried about doing this on Windows.
, although we don't
know yet if it's
On 9/20/13 6:23 PM, Bobby Holley wrote:
It seems like we're going to need a story for this kind of stuff.
Sure. That story may not be WebIDL (e.g. there are proposals to not
have a Date type in IDL at all and just use raw numeric timestamps for
dates).
One major goal of the bindings is to
On 9/20/13 10:02 AM, Benjamin Smedberg wrote:
Hrm. Can profilers (Instruments in particular) profile by C++
namespace?
I don't see a way to do it (keep in mind that it's probably primarily
targeting ObjC, not C++).
It can do things per-symbol and per-library, but those are theoptions.
Bor
It seems like we're going to need a story for this kind of stuff. One major
goal of the bindings is to remove the need for C++ consumers to manually
muck with JSAPI. And as more web objects (TypedArrays, Promises, etc) move
into the JS engine, we're going to want a sane mechanism for manipulating
t
On 9/20/13 3:21 PM, Bobby Holley wrote:
Can you manipulate Dates using the WebIDL bindings instead?
From C++? No.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
I've never used webidl bindings before. Sounds to me that I can somehow
use mozilla::dom::Date in a way that it is part of the xpcom object?
If there is a way to achieve this without jsapi, then I'm fine with it.
Implementing it just shouldn't become overly complicated.
Philipp
On 9/20/13
On 9/20/13 9:06 AM, Benjamin Smedberg wrote:
So I would like to propose that we link the JS libraries statically
into libxul and stop exporting JSAPI symbols entirely. This will
effectively prevent extensions from using it.
To answer questions I received privately about the impact of addon
comp
On 9/20/13 8:22 PM, Benjamin Smedberg wrote:
On 9/20/13 9:06 AM, Benjamin Smedberg wrote:
So I would like to propose that we link the JS libraries statically
into libxul and stop exporting JSAPI symbols entirely. This will
effectively prevent extensions from using it.
To answer questions I rece
Can you manipulate Dates using the WebIDL bindings instead?
On Fri, Sep 20, 2013 at 12:12 PM, Philipp Kewisch wrote:
> On 9/20/13 8:22 PM, Benjamin Smedberg wrote:
>
>> On 9/20/13 9:06 AM, Benjamin Smedberg wrote:
>>
>>> So I would like to propose that we link the JS libraries statically
>>> in
On Fri, Sep 20, 2013 at 6:06 AM, Benjamin Smedberg
wrote:
> Currently, extensions are able to use the JSAPI via its exported symbols.
> This pretty much invariably leads to stability or security issues with
> extensions that actually do this:
>
> * the JSAPI is complicated, and even within Mozilla
On 9/20/2013 9:23 AM, Mike Hommey wrote:
We're already statically linking js libraries info libxul. Except on
windows, but that's work in progress in bug 915735
I am primarily worried about doing this on Windows.
, although we don't
know yet if it's going to work at all: after dealing with the
On Fri, Sep 20, 2013 at 09:06:41AM -0400, Benjamin Smedberg wrote:
> Currently, extensions are able to use the JSAPI via its exported
> symbols. This pretty much invariably leads to stability or security
> issues with extensions that actually do this:
>
> * the JSAPI is complicated, and even withi
Currently, extensions are able to use the JSAPI via its exported
symbols. This pretty much invariably leads to stability or security
issues with extensions that actually do this:
* the JSAPI is complicated, and even within Mozilla we get reviews from
a select set of people on JSAPI code
* the
19 matches
Mail list logo
