Re: Is there any plan to move all DEFINES into moz.build?

Executing: C:\CI-Cor\ks\bolt\bolt-sdk\mozbuild/../mozilla-build/python/python C:\CI-Cor\ks\bolt\bolt-sdk\mozbuild/../../build/BoltBuild.py build Copying C:\CI-Cor\ks\bolt-building\Obj-xulrunner-i686-pc-mingw32-Release\dist\config.status as C:\CI-Cor\ks\bolt\bolt-sdk\Release\build\configStatus.py C

evalinsandbox

Hi All, Can anyone tell me about evalinsandbox?? with examples using addons-sdk?? Thanks in advance. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: About the macro naming prefix NS_

With the caveat that you should maintain consistency with other, similar macros, of course. If you add a new cycle collection macro it should be NS_ prefixed, until someone gets around to renaming all the existing macros. - Kyle On Jul 17, 2015 9:52 PM, "Ehsan Akhgari" wrote: > On 2015-07-17 3:1

Re: Implement Fetch?

To be abundantly clear, no I/O should be happening (or is, to my knowledge) on the main thread when you use XHR. The limitation today is that various Necko state operations (e.g. opening a channel) can only happen on the main thread. But that doesn't mean that we are doing I/O there. - Kyle On Jul

Re: Extra commit metadata on hg.mozilla.org

On Thu, Jun 4, 2015 at 2:10 PM, Gregory Szorc wrote: > hg.mozilla.org now displays extra metadata on changeset pages. e.g. > https://hg.mozilla.org/mozilla-central/rev/dc4023d54436. Read more at > http://gregoryszorc.com/blog/2015/06/04/changeset-metadata-on-hg.mozilla.org/ > > If you notice anyt

Re: Implement Fetch?

On Fri, Jul 17, 2015 at 1:43 PM, David Rajchenbach-Teller wrote: > Would any such reimplementation have an effect on the ability to execute > XHR/Fetch I/O off the main thread? I haven't checked if this has any > consequence in practice, but the idea that all my XHR calls are executed > on the mai

Re: Implement Fetch?

Would any such reimplementation have an effect on the ability to execute XHR/Fetch I/O off the main thread? I haven't checked if this has any consequence in practice, but the idea that all my XHR calls are executed on the main thread is one of the many things in the architecture of Firefox that don

Re: Implement Fetch?

I don't think the problem here is coming up with an architecture, but rather having time to implement it. I think many of the specs you mention would be a lot easier if we implemented the "Hooks for security policies" proposal from [1]. There's already work going on for implementing the "New API f

Re: Implement Fetch?

I thought a little bit more about this after stepping away from my computer. I think some of our implementation issues for service workers currently stems from the fact that the fetch spec and necko have modeled the problem with different primitives: - necko provides an object (nsIChannel) to r

Re: Is there any plan to move all DEFINES into moz.build?

May intention is to treat mozbuild as a relative indpendenent things so we can fast evolve it, and finally merge back to mozilla source tree. 2015-07-18 1:48 GMT+08:00 罗勇刚(Yonggang Luo) : > I've already handled jar.mn and all components things in CommonBackend of > common.py of mozbuild > > Now

Re: Is there any plan to move all DEFINES into moz.build?

I've already handled jar.mn and all components things in CommonBackend of common.py of mozbuild Now leave the DEFINES that needed by some files in the building procedure. My working result at https://github.com/html-shell/mozbuild.git Hope someone can take a look. 2015-07-18 1:10 GMT+08:00 Greg

Re: About the macro naming prefix NS_

> Ehsan Akhgari > July 17, 2015 at 9:52 AM > > > Yes. I think that accurately captures our current practice. > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-pl

Re: Collecting web platform features implementation status

On 17/07/15 16:46, James Graham wrote: On 17/07/15 04:21, Eric Shepherd wrote: Agreed. This is about how we feel about a spec, its content, and the design of its API, not about if or when we will get around to implementing it. That's also something worth capturing, but they're not the same data

Re: Implement Fetch?

On Fri, Jul 17, 2015 at 5:26 PM, Benjamin Kelly wrote: > Do you have specific ideas about how you think things should be refactored? Not really. I believe one of the things that came up was that Necko's interface was not quite ideal and that most of this really ought to be in Necko instead, but I

Re: Implement Fetch?

On Fri, Jul 17, 2015 at 11:20 AM, Anne van Kesteren wrote: > In Whistler we discussed security concerns around service workers and > a lot of them stem from the fact that we don't have a good interface > in Gecko for Fetch[1]. Something that handles requests for all web > platform features we hav

Implement Fetch?

In Whistler we discussed security concerns around service workers and a lot of them stem from the fact that we don't have a good interface in Gecko for Fetch[1]. Something that handles requests for all web platform features we have and deals with CSP, HSTS, Referrer Policy, redirects, service worke

Re: Collecting web platform features implementation status

On 17/07/15 04:21, Eric Shepherd wrote: Agreed. This is about how we feel about a spec, its content, and the design of its API, not about if or when we will get around to implementing it. That's also something worth capturing, but they're not the same data points at all. I think it's the exact

Re: About the macro naming prefix NS_

On 2015-07-17 3:13 AM, Ting-Yu Lin wrote: Currently, the style guide recommends [1]: Macros begin with NS_, and are all caps (e.g. NS_IMPL_ISUPPORTS) It seems that many new macros begin with MOZ_ prefix. Should we fix the style guide and recommend people to use MOZ_ instead of NS_? Yes. I th

Re: Collecting web platform features implementation status

On 16/07/15 21:26, Anthony Ricaud wrote: Potch and I are working on a website to present Mozilla's point of view on various web platform features. Other browsers have similar websites [1] [2] [3]. This project has been in lingo for a while so, to get it out the door, we're going to focus on one i

Re: Collecting web platform features implementation status

Ehsan Akhgari schrieb: I think we need to have a way to signal that we are not going to implement a specific feature in addition to those categories (without delving into the specific example here, but yes this is one of those features.) That sends a useful signal to other browser vendors and we

How to port Firefox's nsContextMenu.js into my customized Gecko based Application?

I want to use Firefox's nsContextMenu implementation for menu support in html pages. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Collecting web platform features implementation status

Anthony, Very very cool idea. About the features encyclopedia: Le 17 juil. 2015 à 04:26, Anthony Ricaud a écrit : > Other browsers have similar websites [2] > [2] https://status.modern.ie fwiw, The IE team has put their project on github. [4] But even better they already have a format for desc

About the macro naming prefix NS_

Currently, the style guide recommends [1]: Macros begin with NS_, and are all caps (e.g. NS_IMPL_ISUPPORTS) It seems that many new macros begin with MOZ_ prefix. Should we fix the style guide and recommend people to use MOZ_ instead of NS_? [1] https://developer.mozilla.org/en-US/docs/Mozilla/De