I wanna to register chrome manifest manually, how to do that?

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

Re: Smart Card and WebCrypto (Re: On the future of and application/x-x509-*-cert MIME handling)

On Sun, Aug 30, 2015 at 12:10 PM, Anne van Kesteren wrote: > it seems they're not using either, so that solution was probably > not sufficient either way. > At least in Spain, is the only way to generate a key pair inside smartcard (using Firefox) before sending PKCS#10 to CA. Then, you go to

[Firefox Desktop] Issues found: August 24th to August 28th

Hi everyone, You can find below the list of new issues found and filed by the Desktop Manual QA team last week (Week 35: August 24 - August 28). Additional details on the team's priorities last week, as well as the plans for the current week can be found at: https://etherpad.mozilla.org/De

Re: NPAPI plug-in use case: certified medical devices

Add-ons that use those APIs can pass review, yes. They would also need to be signed, unless they're using one of the Firefox versions that can disable signing. Jorge On 8/29/15 10:50 AM, Tim Guan-tin Chien wrote: > Will either js-ctypes or child process-calling add-on passes AMO > review? With si

Re: How would you like to spell check this?

On 2015-08-30 4:17 PM, Jörg Knobloch wrote: Obviously the "single language users" who always wanted to write in their mother tongue were left standing in the rain, since they now had to change dictionary many times. That is only true if the majority of the websites on the Internet use the lang

Re: recording use counters for web features

Servo is particularly interested in getting usage data for just about every DOM API that exists in Gecko. We'd like to use this to inform our priorities for implementing missing features in Servo. Is this a realistic request? If not, what about instrumenting all SVG APIs to figure out if there'

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On 8/30/15 5:53 PM, Nicholas Nethercote wrote: I just landed the patches in bug 1198334 that do exactly that. The option has also changed name and is now called ALLOW_COMPILER_WARNINGS. (If you're wondering why I changed the name, it's because it's easier in mozbuild to have an option that defaul

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On 2015-08-31 1:47 PM, Chris Peterson wrote: - About half of those 79 are in third-party code that we do not control (i.e. we regularly update from upstream), for which the option will always be necessary. There may also be some third-party directories in which I didn't add ALLOW_COMPILE

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On Mon, Aug 31, 2015, at 01:47 PM, Chris Peterson wrote: > Should we hold third-party code to the same warning levels as Mozilla's > home-grown code? When we find warnings in third-party code, we typically > just suppress them because they weren't serious issues and fixing them > upstream is ext

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On 8/31/15 11:54 AM, Ted Mielczarek wrote: On Mon, Aug 31, 2015, at 01:47 PM, Chris Peterson wrote: >Should we hold third-party code to the same warning levels as Mozilla's >home-grown code? When we find warnings in third-party code, we typically >just suppress them because they weren't serious

MemShrink Meeting - Tuesday, 1 Sep 2015 at 4:00PM PDT

The next MemShrink meeting is brought to you by better string processing in the HTML5 parser: https://bugzilla.mozilla.org/show_bug.cgi?id=1029671 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss h

Re: How would you like to spell check this?

On 31/08/2015 17:18, Ehsan Akhgari wrote: Just wanting to reiterate that the problem is not as big as you claim it is. We did not break Firefox for "single language users". If you take a good look at the fallback processing in editor/composer/nsEditorSpellCheck.cpp, you will notice that it is

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On Mon, Aug 31, 2015 at 11:09 AM, Ehsan Akhgari wrote: >> >> Should we hold third-party code to the same warning levels as Mozilla's >> home-grown code? > > Yeah, I think in practice it's impossible to hold such code to our > standards. I agree. I wrote the following in the comment describing ALL

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On Mon, Aug 31, 2015 at 12:10 PM, Chris Peterson wrote: > > When I said we have typically suppressed third-party warnings, I meant with > CXXFLAGS += ['-Wno-whatever'] in moz.build I'm not convinced this is worth the effort for "true" third-party code. The next time we update there might be new w

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On Mon, Aug 31, 2015 at 10:47 AM, Chris Peterson wrote: > > In other projects I've worked on, such as closed-source commercial projects > or Chromium, third-party code has been "quarantined" in a top-level vendor > directory (called something like "third_party" [1]). Having third-party code > in o

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

On 2015-08-31 6:36 PM, Nicholas Nethercote wrote: We recently captured a (hopefully full) list of third party code for rewriting purposes under . It looks like a useful starting point for finding third

Re: On the future of and application/x-x509-*-cert MIME handling

On Thursday, 30 July 2015 12:34:30 UTC+2, Anne van Kesteren wrote: > On Thu, Jul 30, 2015 at 12:28 PM, Teoli > wrote: > > Do you think it is already worth to flag it as deprecated in the MDN > > documentation as Google plans to remove it too? > > Yeah, seems worth a note at least given that Micr

Re: On the future of and application/x-x509-*-cert MIME handling

On Thursday, 30 July 2015 20:32:07 UTC+2, Richard Barnes wrote: > On Thu, Jul 30, 2015 at 6:53 AM, Hubert Kario wrote: > > > On Wednesday 29 July 2015 16:35:41 David Keeler wrote: > > > [cc'd to dev-security for visibility. This discussion is intended to > > > happen on dev-platform; please repl