Re: gtests that start XPCOM
Like Ted mentions GTest doesn't support running test in parallel -in the same process-, you have to launch multiple processes which the ./mach gtest command helps you do. Currently GTest has a ScopedXPCOM thing. I'm not sure exactly what this implies however: http://mxr.mozilla.org/mozilla-central/source/testing/gtest/mozilla/GTestRunner.cpp#86 On Wed, Oct 22, 2014 at 2:07 PM, Benjamin Smedberg wrote: > > On 10/22/2014 10:49 AM, Kyle Huey wrote: >> >> I've been wanting this too. I was thinking about just making the gtest >> harness itself start XPCOM. - Kyle > > I don't think that's quite right. 1) We'd have to serialize a bunch of tests > 2) it would be really easy for tests to interfere with eachother. > > What I'd us to do is split gtests into two: keep the existing no-XPCOM > "pure" parallelizable gtests, and have a separate suite which is more like a > binary xpcshell tests: one process per test which uses no profile or a > throwaway profile, and any parallelization is handled by the harness. It > would use the same gtest-libxul so that we could compile in arbitrary test > code which uses internal linkage. > > I'm not sure how hard that would be to implement, though. > > > --BDS > > ___ > 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
Screen Capture
Roc wrote up a proposal last year for a web-facing screen capture API: https://wiki.mozilla.org/User:Roc/ScreenCaptureAPI Even if not web-facing, we could use the implementation code to cover chrome use cases like this one: https://bugzilla.mozilla.org/show_bug.cgi?id=933389 At a recent GFx/Layout work week, we discussed using the Compositor to extract the screen-grab in an efficient, cross-platform manner. It seems we've got enough infrastructure in place to implement this quickly. I'd like options on the API to allow for obscuring text layers so that we could use the images for UI tiles, and other privacy-sensitive use cases. Kicking off this thread to get a discussion on: 1. Web-facing or not? 2. Security/Privacy concerns 3. Implementation concerns 4. Feature requests (eg. blurred or lorem-ipsum text) Other ideas? --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On Fri, Oct 24, 2014 at 10:10 AM, Jet Villegas wrote: > Roc wrote up a proposal last year for a web-facing screen capture API: > https://wiki.mozilla.org/User:Roc/ScreenCaptureAPI > > Even if not web-facing, we could use the implementation code to cover > chrome use cases like this one: > https://bugzilla.mozilla.org/show_bug.cgi?id=933389 > > At a recent GFx/Layout work week, we discussed using the Compositor to > extract the screen-grab in an efficient, cross-platform manner. It seems > we've got enough infrastructure in place to implement this quickly. > > I'd like options on the API to allow for obscuring text layers so that we > could use the images for UI tiles, and other privacy-sensitive use cases. > > Kicking off this thread to get a discussion on: > > 1. Web-facing or not? > I don't think we can. > 4. Feature requests (eg. blurred or lorem-ipsum text) > If you want to blur just text, then we can't use the compositor. We'll have to trigger a repaint from the content side. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
We're already doing screen capture in Firefox 33. Video, not still I think. But the APIs are in place, if the implementation is not. This is not web-facing in the classic sense (https://wiki.mozilla.org/Screensharing) but there are plans to make at least a limited feature set available. Yes, there are massive security implications in that it basically destroys many of the web sandbox protections we work so hard for...if we permit capture of the browser. - Original Message - From: "Jet Villegas" To: "mozilla.dev.platform group" Cc: "Markus Stange" , "Stephen Pohl" , "L. David Baron" , "Ehsan Akhgari" , "Matt Woodrow" , "Jonas Sicking" , "Nicolas Silva" , "Robert O'Callahan" , "Boris Zbarsky" Sent: Thursday, October 23, 2014 2:10:54 PM Subject: Screen Capture Roc wrote up a proposal last year for a web-facing screen capture API: https://wiki.mozilla.org/User:Roc/ScreenCaptureAPI Even if not web-facing, we could use the implementation code to cover chrome use cases like this one: https://bugzilla.mozilla.org/show_bug.cgi?id=933389 At a recent GFx/Layout work week, we discussed using the Compositor to extract the screen-grab in an efficient, cross-platform manner. It seems we've got enough infrastructure in place to implement this quickly. I'd like options on the API to allow for obscuring text layers so that we could use the images for UI tiles, and other privacy-sensitive use cases. Kicking off this thread to get a discussion on: 1. Web-facing or not? 2. Security/Privacy concerns 3. Implementation concerns 4. Feature requests (eg. blurred or lorem-ipsum text) Other ideas? --Jet ___ 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: Screen Capture
On 23/10/2014 22:10, Jet Villegas wrote: Roc wrote up a proposal last year for a web-facing screen capture API: https://wiki.mozilla.org/User:Roc/ScreenCaptureAPI Even if not web-facing, we could use the implementation code to cover chrome use cases like this one: https://bugzilla.mozilla.org/show_bug.cgi?id=933389 At a recent GFx/Layout work week, we discussed using the Compositor to extract the screen-grab in an efficient, cross-platform manner. It seems we've got enough infrastructure in place to implement this quickly. I'd like options on the API to allow for obscuring text layers so that we could use the images for UI tiles, and other privacy-sensitive use cases. Kicking off this thread to get a discussion on: 1. Web-facing or not? Not. Feels like there would be a lot of security issues 2. Security/Privacy concerns Addon's would need to be flagged for using this API. E.g. what if it did screenshots when visiting your bank? 3. Implementation concerns Just for clarification, this would only return the viewport? If so, would full document (at the time call so we don't have to scroll and get into a parallax painful world) be doable? 4. Feature requests (eg. blurred or lorem-ipsum text) David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Changing our help messages to mention --foo options instead of -foo options
Hello. Our command-line option handling is *interesting*. Did you know that: - our options work in -foo form and --foo form; - they are case-insensitive; - this holds for both short options (e.g. -h) and long options (e.g. -help). So, for example, the following are all equivalent: -h, -H, --h, --H. As are -help, --help, -HELP, --HeLp. At least, all this is true for the options that are processed via the main option-processing code. Some of our options are handled elsewhere, via ad hoc code that is generally less flexible. Despite this flexibility, in all our help messages we only mention the -foo form for long options. But -foo options are kind of archaic and --foo options are much more standard these days. So it would be nice to switch to them. In particular, it would avoid messes like |mach run| having a mixture of -foo and --foo options. In bug 1080302 there are r+'d patches for converting all our help messages and almost all of our comments from -foo form to --foo form. (And also for making some of the ad hoc option handling more consistent with the main option handling, and also for making |mach run| use --foo options throughout.) Before I land those patches, I thought I would ask here if anyone can see any reason not to do this. Remember, it's not a functional change -- both -foo and --foo options will still work -- it's just a documentation change. An obvious follow-up is to convert our code to use --foo options instead of -foo options, which is bug 1088430, and slightly riskier. Another obvious follow-up is to drop support for -foo options, but that's *much* harder, so I haven't even bothered filing a bug about that. Thanks. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changing our help messages to mention --foo options instead of -foo options
On Thu, Oct 23, 2014 at 6:20 PM, Nicholas Nethercote wrote: > > > So, for example, the following are all equivalent: -h, -H, --h, --H. On Windows, /h and /H are also equivalent. > As are -help, --help, -HELP, --HeLp. Again on Windows, /help, /HELP, /HelP, etc. are equivalent. As are /-help, /-HELP, etc., though I suspect this is not intentional. (See CheckArg() in nsAppRunner.cpp for the code.) Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Announcing Eclipse CDT IDE Support
A new command has now landed: './mach ide eclipse' and all you need is the eclipse CDT binary on your path. This is your ideal pre-coffee/lunch command and will perform the following: - Rebuild the project - Generate an eclipse workspace + gecko project - Import the mozilla coding style - Launch the eclipse workspace - Index the code base in the background. I've blogged about the benefits of using this before here: http://benoitgirard.wordpress.com/2014/03/10/cc-eclipse-project-generation/ Bug 973770 tracks outstanding improvements. Let me know if you have any comments or questions. - BenWa ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing Eclipse CDT IDE Support
> A new command has now landed: './mach ide eclipse' Nice! Thanks for all your work on this. > will perform the following: > > - Rebuild the project Does this work on B2G? Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
