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

[Yonggang Luo]

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 Copying
C:\CI-Cor\ks\bolt\build\ConfigStatusBolt.py as
C:\CI-Cor\ks\bolt\bolt-sdk\Release\config.status 0:01.36
C:\CI-Cor\ks\bolt\bolt-sdk\Release\_virtualenv\Scripts\python.exe
C:\CI-Cor\ks\bolt\bolt-sdk\Release\config.status --backend=Build
Start building From C:/CI-Cor/ks/bolt/bolt-sdk/Release/dist: Kept
10159 existing; Added/updated 1; Removed 0 files and 0 directories.
Building time is:6.75764342193 seconds


Well, the building time for the whole mozilla source tree is 6 seconds
when no modification is happened.

And the initial building time is about 60s for the first build.

That's almost including all the things except C/C++ files
to building, for those part, I was generating Visual Studio project
files and letting the Visual Studio do the rest things.


If we added a new rule such as CompiledFile,
and add dependencies between each TargetFile and SourceFile,
then we can handling all the rest things such
as generate file script, C/C++ files compiling.
idl files are also handled by now, but in a customized way, if we
add CompiledFile support, we can also treat IDL and xpt as
CompiledFile.

Do know what's the progress in mozilla community, this is my current
work and plan, hope some feedeback.


2015-07-18 6:36 GMT+08:00 Nicholas Nethercote :
>
> On Sat, Jul 18, 2015 at 3:55 AM, Benoit Girard  wrote:
> > Why not continue to make piecework improvements? My understanding is `mach
> > build binaries` now handles .cpp, .h changes only. Why not slowly extend
> > this piece-wise to include .js[m], ipdl, idl, webidl in milestones?
>
> glandium has done and is continuing to do this kind of work. froydnj
> has also chipped in a fair amount. My understanding is that a lot of
> the low-hanging fruit has been picked so it's getting harder.
>
> Nick




-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

evalinsandbox

[Dnyaneshwar Patil]

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_

[Kyle Huey]

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: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 think that accurately captures our current practice.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implement Fetch?

[Kyle Huey]

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 18, 2015 4:43 AM, "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 main thread is one of the many things in the architecture of
> Firefox that don't help me sleep well at night.
>
> Cheers,
>  David
>
>
> On 17/07/15 22:24, Jonas Sicking wrote:
> > 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 for
> > creating channels", "Security Flags" and "Opening channels" sections
> > of [1]. This should be enough to enable channels to know if they have
> > a "tainted" response or not. But we would also need to rearchitecture
> > all relevant callsites to actually look at that. I would imagine some
> > already do, but not all of them.
> >
> > Referrer policies would require other solutions entirely.
> >
> > Anyhow, the short of it is that the missing piece here is having the
> > time to make these changes.
> >
> > [1] https://etherpad.mozilla.org/BetterNeckoSecurityHooks
>
>
> --
> David Rajchenbach-Teller, PhD
>  Performance Team, Mozilla
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extra commit metadata on hg.mozilla.org

[Gregory Szorc]

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 anything wonky, including performance issues, please speak
> up. I'm sure there are corner cases where the parsers aren't picking up
> everything they should. Please link new bugs to bug 1171321.
>
> Changes to hg.mozilla.org's styling are within our control to make
> (unlike say 3rd party hosted services like GitHub) and are generally low
> hanging fruit to implement. If there is something you want the site to do
> to make your life easier, please ask.
>

Ehsan filed bug 1185023 a few hours ago requesting the feature and
hg.mozilla.org now links to Treeherder! e.g.
https://hg.mozilla.org/integration/mozilla-inbound/rev/e65e02c86544

Please keep filing bugs for features you'd like to see on hg.mozilla.org.
Features can literally be rolled out the same day they are filed.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implement Fetch?

[Jonas Sicking]

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 main thread is one of the many things in the architecture of
> Firefox that don't help me sleep well at night.

Yes. One of the goals of the changes in that etherpad is to enable
doing network stuff off the main thread. No one is working on that
part though, and it's not on anyones backlog.

If you're interested, let me know and I'd be happy to point you to the
parts that's needed to archive that specifically.

/ Jonas

> Cheers,
>  David
>
>
> On 17/07/15 22:24, Jonas Sicking wrote:
>> 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 for
>> creating channels", "Security Flags" and "Opening channels" sections
>> of [1]. This should be enough to enable channels to know if they have
>> a "tainted" response or not. But we would also need to rearchitecture
>> all relevant callsites to actually look at that. I would imagine some
>> already do, but not all of them.
>>
>> Referrer policies would require other solutions entirely.
>>
>> Anyhow, the short of it is that the missing piece here is having the
>> time to make these changes.
>>
>> [1] https://etherpad.mozilla.org/BetterNeckoSecurityHooks
>
>
> --
> David Rajchenbach-Teller, PhD
>  Performance Team, Mozilla
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implement Fetch?

[David Rajchenbach-Teller]

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't help me sleep well at night.

Cheers,
 David


On 17/07/15 22:24, Jonas Sicking wrote:
> 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 for
> creating channels", "Security Flags" and "Opening channels" sections
> of [1]. This should be enough to enable channels to know if they have
> a "tainted" response or not. But we would also need to rearchitecture
> all relevant callsites to actually look at that. I would imagine some
> already do, but not all of them.
> 
> Referrer policies would require other solutions entirely.
> 
> Anyhow, the short of it is that the missing piece here is having the
> time to make these changes.
> 
> [1] https://etherpad.mozilla.org/BetterNeckoSecurityHooks


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implement Fetch?

[Jonas Sicking]

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 for
creating channels", "Security Flags" and "Opening channels" sections
of [1]. This should be enough to enable channels to know if they have
a "tainted" response or not. But we would also need to rearchitecture
all relevant callsites to actually look at that. I would imagine some
already do, but not all of them.

Referrer policies would require other solutions entirely.

Anyhow, the short of it is that the missing piece here is having the
time to make these changes.

[1] https://etherpad.mozilla.org/BetterNeckoSecurityHooks

/ Jonas

On Fri, Jul 17, 2015 at 8: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 have and deals with CSP, HSTS, Referrer Policy,
> redirects, service workers, CORS, Mixed Content, etc. for them.
>
> While we decided not do this refactoring before shipping service
> workers, we should probably start planning, unless I'm missing
> something.
>
> [1] https://fetch.spec.whatwg.org/
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implement Fetch?

[Benjamin Kelly]

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 represent the ongoing network
request.  The network request is described as parameters to the creation of
the channel object.  The response is defined as a series of callbacks on
the nsIStreamListener interface.
  - In contrast, fetch defines object primitives for Request and Response,
but has no explicit object to represent the on-going network request.

These are both reasonable ways of doing things, but the impedance mismatch
between the two makes it difficult to accurately translate the new specs
into gecko.  It might be nice to move the DOM code to use the
Request/Response model to align things better with the spec.

One approach we could take would be to add a new internal networking
interface oriented around Request and Response objects.  Internally it
would still use nsIChannel, but would do all the work to translate to and
from Request/Response.  The DOM code would then be modified to create a
Request, call this interface, and then process the returned Response.

We already mostly have this interface in Fetch.h/FetchDriver.h, but we
would probably need to adjust it a bit.  For example, some of the referrer
logic is handled in Fetch.h which requires the use of globals and
Promises.  In theory, though, we should be able to move this into
FetchDriver and provide a clean internal interface to use.

We could then start migrating consumers of NS_NewChannel() to the new
FetchDriver interface.  This would need to be done one-by-one and would
probably run into problems with how to specify internal flags and stuff.
It would be an incremental approach to use a Request/Response oriented
model in the DOM code.

I guess this is probably what you were originally suggesting and I was
jumping to conclusions that you wanted to replace nsIChannel.  Sorry for
that.

Anyway, what do people think?

Ben

On Fri, Jul 17, 2015 at 11:34 AM, Anne van Kesteren 
wrote:

> 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 can't really speak to the code. I'd just like
> us to think about this since our architecture seems quite prone to
> serious security bugs.
>
>
> > I think the only realistic thing we can do is make nsIChannel work more
> like
> > the fetch spec over time.
> >
> > Of course, the main problem will be that we have to support backward
> compat
> > in places the spec might be able to say its making a breaking change
> > compared to the wild web.
>
> If you come across a specification that does that it's a bug in the
> specification. That's not acceptable. If you noticed cases like that
> in Fetch I would very much like to remove them.
>
> If you extend compatibility to add-ons though I can understand that
> refactoring here might get tricky, but hopefully our new add-ons
> efforts can help with that transition?
>
>
> --
> https://annevankesteren.nl/
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Yonggang Luo]

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 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 Gregory Szorc :
>
>> Ideally, yes. But nobody has put in the work for it. I think the reason
>> we haven't seen much effort on continuing to purge Makefiles is because
>> we've hit a local maximum with `mach build binaries`. The next big leap
>> will take considerable investment (likely involves moving lots of logic out
>> of config.mk and rules.mk so we can generate non-make build backends
>> easier/faster).
>>
>> On Tue, Jul 14, 2015 at 3:23 PM, Yonggang Luo 
>> wrote:
>>
>>> This is a blocker to remove all makefiles.
>>> ___
>>> dev-builds mailing list
>>> dev-bui...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-builds
>>>
>>
>>
>
>
> --
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Yonggang Luo]

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 Gregory Szorc :

> Ideally, yes. But nobody has put in the work for it. I think the reason we
> haven't seen much effort on continuing to purge Makefiles is because we've
> hit a local maximum with `mach build binaries`. The next big leap will take
> considerable investment (likely involves moving lots of logic out of
> config.mk and rules.mk so we can generate non-make build backends
> easier/faster).
>
> On Tue, Jul 14, 2015 at 3:23 PM, Yonggang Luo 
> wrote:
>
>> This is a blocker to remove all makefiles.
>> ___
>> dev-builds mailing list
>> dev-bui...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-builds
>>
>
>


-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About the macro naming prefix NS_

[Eric Shepherd]

> 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-platform
> Ting-Yu Lin 
> July 17, 2015 at 3:13 AM
> 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/Developer_guide/Coding_Style#Prefixes
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
I've updated the style guide to that effect; also fixed a few other
layout issues etc on the page, but that's the main thing.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Collecting web platform features implementation status

[Anthony Ricaud]

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 points at all.


I think it's the exact opposite: people want to know what features to
expect in forthcoming Firefox, they don't really care about our feelings
except insofar as the latter influences the former. I think I would have
categories like Implemented [behind a pref] in Firefox X / Under active
development / Intend to implement / Don't intend to implement. Things
that we don't know enough about to decide whether they're a good idea to
implement or not can simply be left off the list; if we have nothing
useful to say about technology X it's better to say nothing at all.
Specifying when something shipped or will ship is clearly a non-goal for 
this first iteration. Plenty of resources already provide this 
information, starting with caniuse and MDN.


Once we have the first iteration shipped, we can look at adding more 
data points.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implement Fetch?

[Anne van Kesteren]

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 can't really speak to the code. I'd just like
us to think about this since our architecture seems quite prone to
serious security bugs.


> I think the only realistic thing we can do is make nsIChannel work more like
> the fetch spec over time.
>
> Of course, the main problem will be that we have to support backward compat
> in places the spec might be able to say its making a breaking change
> compared to the wild web.

If you come across a specification that does that it's a bug in the
specification. That's not acceptable. If you noticed cases like that
in Fetch I would very much like to remove them.

If you extend compatibility to add-ons though I can understand that
refactoring here might get tricky, but hopefully our new add-ons
efforts can help with that transition?


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implement Fetch?

[Benjamin Kelly]

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 have and deals with CSP, HSTS, Referrer Policy,
> redirects, service workers, CORS, Mixed Content, etc. for them.
>
> While we decided not do this refactoring before shipping service
> workers, we should probably start planning, unless I'm missing
> something.
>
> [1] https://fetch.spec.whatwg.org/


Do you have specific ideas about how you think things should be refactored?

I think the only realistic thing we can do is make nsIChannel work more
like the fetch spec over time.

Of course, the main problem will be that we have to support backward compat
in places the spec might be able to say its making a breaking change
compared to the wild web.

Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Implement Fetch?

[Anne van Kesteren]

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 workers, CORS, Mixed Content, etc. for them.

While we decided not do this refactoring before shipping service
workers, we should probably start planning, unless I'm missing
something.

[1] https://fetch.spec.whatwg.org/


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Collecting web platform features implementation status

[James Graham]

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 opposite: people want to know what features to 
expect in forthcoming Firefox, they don't really care about our feelings 
except insofar as the latter influences the former. I think I would have 
categories like Implemented [behind a pref] in Firefox X / Under active 
development / Intend to implement / Don't intend to implement. Things 
that we don't know enough about to decide whether they're a good idea to 
implement or not can simply be left off the list; if we have nothing 
useful to say about technology X it's better to say nothing at all.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About the macro naming prefix NS_

[Ehsan Akhgari]

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 think that accurately captures our current practice.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Collecting web platform features implementation status

[Anthony Ricaud]

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 information: what is Mozilla's
opinion on features that have not been shipped yet. We see 4 possible
answers: in development, favorable, not favorable, no opinion.

In order to get accurate data and update it regularly, we need your
help. Please go to the following etherpad and insert any information
that can help us:
https://etherpad.mozilla.org/gecko-web-platform-dashboard

Thanks for your help!

[1] https://www.chromestatus.com/features
[2] https://status.modern.ie
[3] http://www.webkit.org/status.html
This has now moved to Github: 
https://github.com/Rik/platform-status/blob/master/features.json

You can also email me directly if pull requests are not your thing.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Collecting web platform features implementation status

[Robert Kaiser]

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 web
developers.  I know that for us, it would be hugely helpful to know if
vendor X is actively planning to not implement a certain feature when
weighing the pros and cons of working on something.  I can imagine the
same would be useful for other vendors, and it would be nice if we did
that.


I agree, but I think we should have a wording that says something like 
"opposed to implementation" or similar and not "we will not implement", 
as we have seen in the past that things we didn't want to be implemented 
(that way) did actually pick up steam elsewhere and we ended up still 
implementing it - both for things that are not in line with our 
philosophy of the web, like EME, and for things where we had competing 
proposals (which we thought were the better way to go), like WebAudio.


KaiRo

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Yonggang Luo]

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

[Karl Dubost]

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 describing the features. [5]

Maybe it would be to use something very similar if not the exact same thing, so 
someone who would like to import all browser vendors into one, end up having 
less headaches.

[4]: https://github.com/MicrosoftEdge/Status
[5]: 
https://github.com/MicrosoftEdge/Status/blob/production/app/static/ie-status.json

-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

About the macro naming prefix NS_

[Ting-Yu Lin]

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/Developer_guide/Coding_Style#Prefixes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform