Re: Proposal: stop exporting JS symbols

2013-09-23 Thread Philipp Kewisch
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

Re: C++ Standards Committee meeting next week

2013-09-23 Thread Joshua Cranmer 🐧
On 9/20/2013 4:50 PM, Botond Ballo wrote: Hi everyone, The C++ Standards Committee is meeting in Chicago next week. Their focus will be on C++14, the upcoming version of the C++ standard, as well as some Technical Specifications (specifications for features intended to be standardized but not

Re: C++ Standards Committee meeting next week

2013-09-23 Thread Gregory Szorc
On 9/20/13 2:50 PM, Botond Ballo wrote: Hi everyone, The C++ Standards Committee is meeting in Chicago next week. Their focus will be on C++14, the upcoming version of the C++ standard, as well as some Technical Specifications (specifications for features intended to be standardized but not f

Re: C++ Standards Committee meeting next week

2013-09-23 Thread Robert O'Callahan
On Tue, Sep 24, 2013 at 5:18 AM, Trevor Saunders wrote: > - virtual constants > Yeah baby! > - ability to say classes should only be used on stack / heap or not used > in one of those > That's another good idea! Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eov

Re: Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Brian Smith
On Mon, Sep 23, 2013 at 3:40 PM, Chris Peterson wrote: > On 9/23/13 2:41 PM, Benjamin Smedberg wrote: > Even if Firefox supported the Pepper API, we would still need a Pepper > version of Flash. And Adobe doesn't have one; Google does. > > When I was an engineer on Adobe's Flash Player team, Googl

Re: Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Brian Smith
On Mon, Sep 23, 2013 at 2:41 PM, Benjamin Smedberg wrote: > On 9/23/2013 4:59 PM, Brian Smith wrote: > >> Given that Pepper presents little benefit to users, >>> >> >> Pepper presents a huge benefit to users because it allows the browser to >> sandbox the plugin. Once we have a sandbox in Firefox,

Re: Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Chris Peterson
On 9/23/13 2:41 PM, Benjamin Smedberg wrote: * That "the plugin" is only Flash. No other plugin has Pepper or is likely to use pepper. And a significant number of users are still using non-Flash plugins. * That we could have a pepper Flash for Firefox in a reasonable timeframe (highly unlikely gi

Re: Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Benjamin Smedberg
On 9/23/2013 4:59 PM, Brian Smith wrote: Given that Pepper presents little benefit to users, Pepper presents a huge benefit to users because it allows the browser to sandbox the plugin. Once we have a sandbox in Firefox, NPAPI plugins will be the security weak spot in Firefox. You're making so

Re: Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Brian Smith
On Mon, Sep 23, 2013 at 1:46 PM, Benjamin Smedberg wrote: > On 9/23/2013 4:29 PM, Hubert Figuière wrote: > >> Hi all, >> >> Today Google said they'd drop NPAPI for good. >> > We also intend to someday drop NPAPI for good. I don't think that "by the > end of 2014" is a realistic timeline for either

Re: Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Brian Smith
On Mon, Sep 23, 2013 at 1:46 PM, Benjamin Smedberg wrote: > The costs of Pepper are huge: it is not a well-specified API; we'd be > reverse-engineering large bits of chromium code in order to support it, and > it's clear that we want to focus effort on the web not Pepper. I asked some Chromium g

Re: Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Andreas Gal
Pepper is not an API, its basically a huge set of Chromium guts exposed you can link against. The only documentation is the source, and that source keeps constantly changing. I don't think its viable for anyone to implement Pepper without also pulling in most or all of Chromium. Pepper is Chrom

Re: Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Benjamin Smedberg
On 9/23/2013 4:29 PM, Hubert Figuière wrote: Hi all, Today Google said they'd drop NPAPI for good. We also intend to someday drop NPAPI for good. I don't think that "by the end of 2014" is a realistic timeline for either Chrome or us, given the number of users who still rely on Java and other

Re: Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Jet Villegas
The only Pepper plug-in worth talking about is the Flash Player. The Flash Player that ships in Chrome is developed by Google and distributed with the Chrome browser. That is, Adobe doesn't make this Pepper plug-in and has no installers for Firefox users to use. In other words, Pepper support do

Implementing Pepper since Google is dropping NPAPI for good

2013-09-23 Thread Hubert Figuière
Hi all, Today Google said they'd drop NPAPI for good. http://news.cnet.com/8301-1023_3-57604242-93/google-begins-barring-browser-plug-ins-from-chrome/ Bug 729481 was WONTFIXED a while ago. tl;dr : implement Pepper plugin API I think it might be worth the revisit that decision before it is too l

Re: You want faster builds, don't you?

2013-09-23 Thread Neil
Steve Fink wrote: My anecdote: about 2 years ago, I did a lot of building on Windows and tried very hard to use a VM (just one layer -- a Windows 7 Virtualbox VM inside Fedora x64.) The configure times were excruciating. 6 minutes sounds about right -- for the top-level configure only. If you

Re: Proposal: stop exporting JS symbols

2013-09-23 Thread Ehsan Akhgari
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

Re: Proposal: stop exporting JS symbols

2013-09-23 Thread Benjamin Smedberg
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

Re: C++ Standards Committee meeting next week

2013-09-23 Thread Trevor Saunders
Hi, some things that I've seen that we'd probably like to see end up in the language include. - final on data / non virtual member functions - virtual constants (maybe ability to get at vtable pointer too?) - ability to say classes should only be used on stack / heap or not used in one of those

Re: You want faster builds, don't you?

2013-09-23 Thread Trevor Saunders
> [I also see a clobber build spend > 5 minutes in various configure > runs, which frustrates me every time I see it - so I minimize the > shell ;] > >>> > >>>We don't have much love for configure either. However, it's only > >>>contributing a few extra minutes to Windows builds compare

Re: Add-ons Firefox 24 crash due to recent change in JSAPI

2013-09-23 Thread Bobby Holley
On Mon, Sep 23, 2013 at 5:12 AM, wrote: > Thanks a lot Bobby. > My issue is solved after use of nsCxPusher for JSContext. > Could you suggest me some alternative approach to do the same? > An alternative to nsCxPusher? My suggestion is to not use JSAPI, period. Per another discussion on this lis

Rendering meeting, (today) Monday 2;30pm PDT ("the early time")

2013-09-23 Thread Milan Sreckovic
The Rendering meeting is about all things Gfx, Image, Layout, and Media. It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm PDT. The next meeting will take place today Monday, September 23 at 2:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Plat

Re: You want faster builds, don't you?

2013-09-23 Thread Benoit Girard
On Mon, Sep 23, 2013 at 12:49 AM, Robert O'Callahan wrote: > I observe that Visual Studio builds do not spawn one cl process per > translation unit. Knowing how slow Windows is at spawning processes, I > suspect the build would be a lot faster if we used a single cl process to > compile multiple t

Re: You want faster builds, don't you?

2013-09-23 Thread Joshua Cranmer 🐧
On 9/23/2013 1:10 AM, Gregory Szorc wrote: ~6 minutes for a configure?! I just did a configure from a clobber build on Windows on my i7-2600K (2+ year old CPU) and it took 2:10. If you are seeing 6 minutes configure times, you are running an ancient CPU and/or not an SSD or you have something fub

Re: Proposal: stop exporting JS symbols

2013-09-23 Thread Philipp Kewisch
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

Re: Proposal: stop exporting JS symbols

2013-09-23 Thread Benjamin Smedberg
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

Re: You want faster builds, don't you?

2013-09-23 Thread Benjamin Smedberg
On 9/23/2013 1:38 AM, Anthony Jones wrote: On 23/09/13 16:49, Robert O'Callahan wrote: I see how compiling several files in the same cl invocation would mess up using /showincludes to track dependencies, making this difficult to fix. The only possibility I can think of for fixing this is to emit

Re: Add-ons Firefox 24 crash due to recent change in JSAPI

2013-09-23 Thread vasuyadavkrishn
On Thursday, September 19, 2013 10:06:30 AM UTC+5:30, vasuyad...@gmail.com wrote: > Hi > > > > We are facing problem with our Add-ons support for FireFox 24.Firefox is > crashing. In earlier approach we was using 'JS_GetGlobalObject' to get global > object from docShell. > https://developer

Re: You want faster builds, don't you?

2013-09-23 Thread Mark Hammond
On 23/09/2013 4:10 PM, Gregory Szorc wrote: thread and to every armchair quarterback that shows up. Really? :( [I also see a clobber build spend > 5 minutes in various configure runs, which frustrates me every time I see it - so I minimize the shell ;] We don't have much love for configure