Intent to implement and ship: ImageCapture
Summary: Allow web authors to take photo via gUM video track. Bug: Main tracking bug, https://bugzilla.mozilla.org/show_bug.cgi?id=888177 Spec: https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/ImageCapture.html Platform coverage: All platforms. Target release: late 2014. Pref: dom.imagecapture.enabled Background: The spec is pretty much a draft. I focus on implementing subset needs to take advantage of high resolution camera hardware in platform like B2G [1]. Best regards, Alfredo [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1054905 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Web APIs documentation meeting Friday at 10 AM PDT
The Web APIs documentation meeting is Friday at 10 AM Pacific Time (see http://bit.ly/APIdocsMDN for your time zone). Everyone's welcome to attend; if you're interested in ensuring that all Web APIs are properly documented, we'd love your input. We have an agenda, as well as details on how to join, here: https://etherpad.mozilla.org/WebAPI-docs-2014-09-05. If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! If you're unable to attend but have been working on documentation related to APIs, please add notes to the agenda about what you've been doing so we can share your progress. -- Eric Shepherd Developer Documentation Lead Mozilla Blog: http://www.bitstampede.com/ Twitter: @sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Structured Logging update
Myself and others on Automation and Tools have undertaken an effort to convert our test harnesses to use structured logging. We are making this conversion to allow our testing infrastructure to move away from regex based log parsing and to expose more useful log data (with a focus on test results as JSON) to a wider variety of consumers. Ahmed Kachkach, an intern with the A*Team this summer posted earlier with an update about Mochitests. I'm following up here with pointers to more information. Documentation for the python logging library we're building on (mozlog) is available on readthedocs[1] and includes some examples if you're curious about how this works. I've written up a short wiki page [2] including some background on the project, and we’ve been using bug 916295 [3] to track progress. We're intending to provide a foundation for future tools and infrastructure improvements without disrupting familiar workflows or breaking compatibility with existing tools, so the changes will be largely unobtrusive at this stage. If you have trouble running tests locally or observe undesired changes to test harness output, this could be an unintended side effect of this work that needs to be addressed. Ping me (chmanchester) in #ateam if you have any questions. Bugs/features for mozlog should be filed in Testing :: Mozbase. [1] http://mozbase.readthedocs.org/en/latest/mozlog_structured.html [2] https://wiki.mozilla.org/Auto-tools/Projects/Structured_Logging [3] https://bugzilla.mozilla.org/show_bug.cgi?id=916295 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Fennec 32 Password Manager issues
Are there any known issues with the Password Manager on Fennec 32? When I try to use a saved password it does not fill the field in. Pulling up Mobile Password Manager, just gives me an error saying the Master Password was not entered. (There is no Master Password.) If I re-install 31 everything works fine again. I noticed that Firefox 32 switches from signons.sqlite to logins.json. Is the migration not working on mobile? Would deleting the profile and re-syncing fix it? Wesley Hardman ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: WebCrypto API
As of September we intend to enable the WebCrypto API by default on all platforms. It has been developed behind the dom.webcrypto.enabled preference. Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=865789 Spec: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html (A CR is planned soon, only smaller changes to the spec lately.) Reasoning: The implementation of the WebCrypto API has made lots of progress in Firefox 33+34. We added most of the basic functionality and algorithms, and should be mostly spec compliant. Chromium has had the WebCrypto API enabled by default since Crome 37, which was released in late June 2014. Their implementation supports a subset of the algorithms that we do, and has roughly the same level of spec compliance. We expect the two implementations to be mostly interoperable as-is, with some fine points being ironed out as the spec is finalized. We thus propose to enable the WebCrypto API by default for all platforms to get some more feedback from developers and give them the opportunity to use new functionality. - Tim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fennec 32 Password Manager issues
On 3/09/2014 19:31, Wesley Hardman wrote: > Are there any known issues with the Password Manager on Fennec 32? > When I try to use a saved password it does not fill the field in. > Pulling up Mobile Password Manager, just gives me an error saying the > Master Password was not entered. (There is no Master Password.) If > I re-install 31 everything works fine again. I noticed that Firefox > 32 switches from signons.sqlite to logins.json. Is the migration not > working on mobile? Would deleting the profile and re-syncing fix > it? Did you file a bug for this? -- GCP ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fennec 32 Password Manager issues
Not yet. Thought I would ask and see if there was anything known before filing a bug. Especially if it is something peculiar to me. On 2014-09-03 14:03, Gian-Carlo Pascutto wrote: > On 3/09/2014 19:31, Wesley Hardman wrote: >> Are there any known issues with the Password Manager on Fennec 32? >> When I try to use a saved password it does not fill the field in. >> Pulling up Mobile Password Manager, just gives me an error saying the >> Master Password was not entered. (There is no Master Password.) If >> I re-install 31 everything works fine again. I noticed that Firefox >> 32 switches from signons.sqlite to logins.json. Is the migration not >> working on mobile? Would deleting the profile and re-syncing fix >> it? > > Did you file a bug for this? > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Sheriffs] Aurora is closed
The nightlies magically unbusted themselves. Aurora is open for business again. -Ryan - Original Message - From: "Kevin Grandon" To: "dev-gaia" , "dev-b2g" , "dev-platform" Cc: "Sheriffs" Sent: Tuesday, September 2, 2014 9:35:55 PM Subject: [Sheriffs] Aurora is closed "Since today's uplift, B2G emulator dep builds (regular per-push builds) are running and passing tests. However, *nightly* builds are a sea of orange. So this mostly likely comes down to build config differences between dep builds and nightly builds. Aurora is closed until the cause of this is found and fixed." Follow along here: https://bugzilla.mozilla.org/show_bug.cgi?id=1062032 If you have any ideas about what might be causing this please chime in on the bug. ___ Sheriffs mailing list sheri...@mozilla.org https://mail.mozilla.org/listinfo/sheriffs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: WebCrypto API
I'm excited to see this finally happen! Can you please clarify what are the areas that we don't fully adhere to the spec? Do we expect the fixes to those and potentially new spec issues in the future to break backwards compatibility? Thanks! Ehsan On 2014-09-03, 1:36 PM, Tim Taubert wrote: As of September we intend to enable the WebCrypto API by default on all platforms. It has been developed behind the dom.webcrypto.enabled preference. Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=865789 Spec: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html (A CR is planned soon, only smaller changes to the spec lately.) Reasoning: The implementation of the WebCrypto API has made lots of progress in Firefox 33+34. We added most of the basic functionality and algorithms, and should be mostly spec compliant. Chromium has had the WebCrypto API enabled by default since Crome 37, which was released in late June 2014. Their implementation supports a subset of the algorithms that we do, and has roughly the same level of spec compliance. We expect the two implementations to be mostly interoperable as-is, with some fine points being ironed out as the spec is finalized. We thus propose to enable the WebCrypto API by default for all platforms to get some more feedback from developers and give them the opportunity to use new functionality. - Tim ___ 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: PSA: ./mach build doesn't work reliably any longer
On Mon, Aug 25, 2014 at 5:48 PM, Nicholas Nethercote wrote: > > - |mach build binaries| is awesome. Here's an illustrative story. In my .bashrc file I have *18* aliases for building subdirectories within Firefox: js, xpconnect, xpcom, layout, etc. I used to use them all the time... but I only now realized that I haven't used any of them in months. |mach build binaries| suffices most of the time, and when I do change something other than a .h/.cpp file, I just use |mach build| and my fast machine (with ccache) builds quickly enough. That's a nice reduction in mental load, and it greatly reduces the chance of frankenbuilds. Not everyone will have the same code modification patterns as me, but plenty will. I call that progress. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
On 9/3/14, 6:53 PM, Nicholas Nethercote wrote: |mach build binaries| suffices most of the time It really doesn't for the use case of not building the world when you change a header and want to just rebuild the files that use the changed part of the header... I should also note that a completely no-op "mach build binaries" is about 5s for me. :( -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
On Wed, Sep 03, 2014 at 08:52:30PM -0400, Boris Zbarsky wrote: > On 9/3/14, 6:53 PM, Nicholas Nethercote wrote: > >|mach build binaries| suffices most of the time > > It really doesn't for the use case of not building the world when you change > a header and want to just rebuild the files that use the changed part of the > header... > > I should also note that a completely no-op "mach build binaries" is about 5s > for me. :( I guess this comes from installing test files. We should get that off mach build binaries. Please file a bug with a timestamped log. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
On 9/3/14, 10:10 PM, Mike Hommey wrote: Please file a bug with a timestamped log. Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1062668 And thank you! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Some more changes to declarations in the build system
Hi, I just landed a few changes to how programs and libraries are declared in moz.build. See the last version of the documentation: https://hg.mozilla.org/integration/mozilla-inbound/file/tip/build/docs/defining-binaries.rst or, you can see what changed, specifically: https://hg.mozilla.org/integration/mozilla-inbound/diff/01a0e2c9c595/build/docs/defining-binaries.rst https://hg.mozilla.org/integration/mozilla-inbound/diff/17bee965226a/build/docs/defining-binaries.rst https://hg.mozilla.org/integration/mozilla-inbound/diff/8b5e3ba0f83d/build/docs/defining-binaries.rst That shouldn't change much for most people, and in case you have patches using the old syntax, the errors should be self-explanatory as to what specific changes you'd need to do. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
On Wed, Sep 3, 2014 at 5:52 PM, Boris Zbarsky wrote: > On 9/3/14, 6:53 PM, Nicholas Nethercote wrote: >> >> |mach build binaries| suffices most of the time > > It really doesn't for the use case of not building the world when you change > a header and want to just rebuild the files that use the changed part of the > header... I guess the "most of the time" wasn't enough of a qualifier. How about "|mach build binaries| suffices most of the time, for me, on my machine, for my work patterns"? Sorry. This thread is making me grumpy. Lots of negativity. Not a lot of constructive suggestions. Everyone is aware that the current situation isn't perfect. I'm just trying to demonstrate that not everything completely sucks for everyone all the time. I give kudos to the build team for the progress that they are making. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
On Wed, Sep 3, 2014 at 8:47 PM, Nicholas Nethercote wrote: >> >> It really doesn't for the use case of not building the world when you change >> a header and want to just rebuild the files that use the changed part of the >> header... Thinking about this some more... The standard ideal build system is one that rebuilds exactly the files that depend on input files that have changed. What you're asking for is something beyond that -- you want sub-file dependency tracking, because we (unfortunately) have some files that are depended on by many other files. But in lieu of sub-file dependency tracking you'll take manual overrides that emulate them by doing partial builds, relying on your knowledge of the codebase to know that those partial builds are safe. In other words, you want to treat the build system not as a black box. That seems like a difficult requirement to satisfy, especially in a way that isn't prone to breakage over time. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
On Wed, Sep 3, 2014 at 9:26 PM, Nicholas Nethercote wrote: > What you're asking for is something beyond that -- you want sub-file > dependency tracking, because we (unfortunately) have some files that > are depended on by many other files. But in lieu of sub-file > dependency tracking you'll take manual overrides that emulate them by > doing partial builds, relying on your knowledge of the codebase to > know that those partial builds are safe. In other words, you want to > treat the build system not as a black box. > > That seems like a difficult requirement to satisfy, especially in a > way that isn't prone to breakage over time. > Sure, but if there are enough core developers who gain an order of magnitude in turnaround time by being able to do this (and there are certainly quite a few in this thread), it's probably worth finding some way to support. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
On 9/4/14, 12:26 AM, Nicholas Nethercote wrote: But in lieu of sub-file dependency tracking you'll take manual overrides that emulate them by doing partial builds, relying on your knowledge of the codebase to know that those partial builds are safe. This is a point worth clarifying. I'm not trying to produce a build when I want these manual overrides. I'm trying to check that some small set of files that actually uses a new function I added compiles correctly before I spend the time to do a more complete compile that actually produces a build. I mean, if I add a new virtual function to nsINode and then only compile the subset of files that call the new function, I _know_ the resulting build if I linked libxul is busted: different parts of it think the vtable looks different. But this is still a useful thing to be able to do as I iterate on my API addition! I realize that the main goal of the build system is producing an actual working build. But while doing development this may not be a goal at intermediate stages... That seems like a difficult requirement to satisfy That, I agree on. Build systems are very geared toward "create the build that has everything updated", not "test these changes compile in a small part of this large interwingled codebase" -Boris P.S. "large interwingled codebase" is key; if my habitual full build were the SpiderMonkey shell, say, I would care a lot less about partial builds. Though even then, if I change MIR.h having a way to just recompile CodeGenerator.cpp and IonBuilder.cpp and make sure those compile before I compile all the other js/src/jit stuff sure would be nice... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
On 9/3/2014 11:45 PM, Boris Zbarsky wrote: I mean, if I add a new virtual function to nsINode and then only compile the subset of files that call the new function, I _know_ the resulting build if I linked libxul is busted: different parts of it think the vtable looks different. But this is still a useful thing to be able to do as I iterate on my API addition! It sounds to me like what you really want is support for a red squiggly line in your IDE, or the nearest equivalent to it in your development environment. This effectively requires being able to say, for any source file, the exact command and arguments needed to make it compile, plus appropriate hookups to your IDE. Being able to have moz.build spit this out has been an aspiration of mine for some time, and I believe we are capable of making this possible by the end of the year. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
On 9/4/14, 12:51 AM, Joshua Cranmer 🐧 wrote: It sounds to me like what you really want is support for a red squiggly line in your IDE Not quite, because red squiggly lines don't catch weird C++ namespacing rules, lack of conversion operators that should be present, etc... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build doesn't work reliably any longer
> From: "Boris Zbarsky" > To: dev-platform@lists.mozilla.org > Sent: Thursday, September 4, 2014 1:24:58 AM > Subject: Re: PSA: ./mach build doesn't work reliably any longer > > On 9/4/14, 12:51 AM, Joshua Cranmer 🐧 wrote: > > It sounds to me like what you really want is support for a red squiggly > > line in your IDE > > Not quite, because red squiggly lines don't catch weird C++ namespacing > rules, lack of conversion operators that should be present, etc... They can if they are produced by running (the front-end of) a compiler on the source files in question and parsing its output. Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: WebCrypto API
I'll love to know if Mozilla/Firefox is going to provide something (even out-of-standard) to make possible using PKCS#11/NSS with Webcrypto. This will fill the gap that currently exist with hardware token support (which, is going to be discussed nexr 10th September) Regards. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: WebCrypto API
On Wed, Sep 3, 2014 at 7:36 PM, Tim Taubert wrote: > Chromium has had the WebCrypto API enabled by default since Crome 37, > which was released in late June 2014. Their implementation supports a > subset of the algorithms that we do, and has roughly the same level of > spec compliance. We expect the two implementations to be mostly > interoperable as-is, with some fine points being ironed out as the spec > is finalized. Is there a list of algorithms we support somewhere, particularly the ones we share with Chromium? IIRC the supported algorithms is where the real interop problems are expected to be. (I quickly searched MDN, but that didn't turn up anything useful.) Cheers, Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
