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
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:
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
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
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
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 within
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 6:06 AM, Benjamin Smedberg
benja...@smedbergs.us 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
Can you manipulate Dates using the WebIDL bindings instead?
On Fri, Sep 20, 2013 at 12:12 PM, Philipp Kewisch mozi...@kewis.ch 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
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
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
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
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
13 matches
Mail list logo
