On Thu, Mar 20, 2014 at 5:52 PM, Neil wrote:
>
>>
> Sure, but the old category only installed the object on demand, so this is
> a backward step...
What is your concern, exactly? Performance? I doubt it's significant. You
could define the object with lazy getters if you wanted.
bholley
___
Bobby Holley wrote:
On Tue, Mar 18, 2014 at 6:53 AM, Neil wrote:
Let's suppose that I want to provide a global property that provides 5
functions each with a number of string arguments. (Traditionally this would be
done using a component in the JavaScript global property category.) How woul
On Tue, Mar 18, 2014 at 6:53 AM, Neil wrote:
> Let's suppose that I want to provide a global property that provides 5
> functions each with a number of string arguments. (Traditionally this would
> be done using a component in the JavaScript global property category.) How
> would this way work? (
Boris Zbarsky wrote:
On 3/17/14 9:25 AM, Benjamin Smedberg wrote:
Do we not have a safe way now to expose objects and functions to
pages (all pages or some pages)?
We have a way that can be safe as long as you're really careful about
some things. e.g. if your API takes options objects, you
> On Mon, Mar 17, 2014 at 10:25 AM, Benjamin Smedberg
> wrote:
>
> > Maybe this means we should consider exposing some kind of structured-clone
> > system for calling untrusted code, plus a safer way to call functions which
> > may return arbitrary results?
> >
>
> This actually already exists. C
On Mon, Mar 17, 2014 at 10:25 AM, Benjamin Smedberg
wrote:
> Maybe this means we should consider exposing some kind of structured-clone
> system for calling untrusted code, plus a safer way to call functions which
> may return arbitrary results?
>
This actually already exists. Cu.exportFunction (
On 3/17/14 9:25 AM, Benjamin Smedberg wrote:
Isn't this something which pagemod addons and greasemonkey already do?
To some extent. In a lot of cases, those are running with the principal
of the page, not with a system principal; that makes a big difference.
Do we not have a safe way now t
On 3/14/2014 11:26 PM, Boris Zbarsky wrote:
For non-core, if you control the Gecko you build against, then the
answer is the same. If you have to work against a random Gecko,
that's a problem we don't have a good solution for yet.
Assuming you really need to expose the object to a web page.
On 3/15/14 4:31 PM, smaug wrote:
I think we should add some checks to test_interfaces to enforce this.
(Assuming we can detect xpcom stuff via different kind of prototypes vs.
webidl implemented stuff)
We actually can: the toString() in the prototype object returns very
different things in the
On 03/14/2014 11:20 PM, Boris Zbarsky wrote:
We're at a point where we are actively trying to eliminate xpconnect usage on
the web.
I'm happy to enumerate the reasons we're doing that if people care, but the
practical upshot is:
1) Do not add new objects with classinfo to nsDOMClassInfo.cpp
On 3/14/14 7:09 PM, Neil wrote:
Not that I'm planning on adding any new components, but what
alternatives are there, particularly for non-core consumers?
For core consumers, JS-implemented WebIDL is the way to go.
For non-core, if you control the Gecko you build against, then the
answer is th
Boris Zbarsky wrote:
Do not add new JavaScript components with DOM_OBJECT classinfo
(period; I can't think of reasons this would be needed).
Not that I'm planning on adding any new components, but what
alternatives are there, particularly for non-core consumers?
--
Warning: May contain trac
We're at a point where we are actively trying to eliminate xpconnect
usage on the web.
I'm happy to enumerate the reasons we're doing that if people care, but
the practical upshot is:
1) Do not add new objects with classinfo to nsDOMClassInfo.cpp unless
you've explicitly been told it's OK b
13 matches
Mail list logo
