Running C-C TB under valgrind during mozmill test: extending timeout values (but where?)

I wonder if someone has any idea about the following issues: I used to be able to run C-C TB under valgrind by creating a wrapper binary during mozmill test. This wrapper is named as .../dist/bin/thunderbird and invokes thunderbird-bin under valgrind. By extending, timeout values in a few places

Re: New Developer Tools Feature: prettifying JSON

Jan, Le 16 avr. 2015 à 01:54, Jan Odvarko a écrit : > One of the new features we'd like to have in DevEdition 40 is related to > JSON rendering. Prettifying JSON is a good idea. Did you check/play with jq? https://stedolan.github.io/jq/ https://jqplay.org/ They do a really good job at showing

Re: Intent to deprecate: Insecure HTTP

As Robert is saying: Le 16 avr. 2015 à 00:29, Robert Kaiser a écrit : > I think we need to think very hard about what reasons people have to still > not use TLS and how we can help them to do so. Definitely. The resistance in this thread is NOT about "people against security", but 1. we want t

Re: Intent to deprecate: Insecure HTTP

On Wed, Apr 15, 2015 at 10:44:35AM +0100, Gervase Markham wrote: > On 14/04/15 22:59, northrupthebandg...@gmail.com wrote: > > The article assumes that when folks connect to something via SSH and > > something changes - causing MITM-attack warnings and a refusal to > > connect - folks default to ju

Re: New Developer Tools Feature: prettifying JSON

On 4/15/15 12:54 PM, Jan Odvarko wrote: This approach has one security implication, if the page uses "default-src 'none'" (or other security restrictions?) - injecting JS into it generates warnings: "Content Security Policy: The page's settings blocked the loading of a resource at self ("default-

Intent to implement and ship AudioContext.{suspend,resume,close}

Summary: AudioContexts are very useful objects, but they use quite a lot of CPU time (they use a very high priority thread that wakes up often to compute and output audio), keep the audio hardware awake and in low latency mode. In other words, authors should try to dispose of their AudioContext whe

New Developer Tools Feature: prettifying JSON

One of the new features we'd like to have in DevEdition 40 is related to JSON rendering. Dev folks deal with JSON a lot these days and we want to make the work easier by rendering JSON as an expandable tree that allows easy inspection and filter/search. One option to make this is implementing a st

Re: Intent to deprecate: Insecure HTTP

On Wed, Apr 15, 2015 at 5:20 PM, Robert Kaiser wrote: > Are there any good proposals on how to make those decently secure and keep > them easy to use? I believe Chrome is experimenting with different UI for self-signed certificates when connecting to a local server. A good outline of the problem

Re: Runnables and thread-unsafe members

Sounds good to me as well. On 2015-04-14 5:44 PM, Bobby Holley wrote: +1. On Tue, Apr 14, 2015 at 2:42 PM, Kyle Huey wrote: On Tue, Apr 14, 2015 at 2:39 PM, Randell Jesup wrote: (was: Re: Proposal to ban the usage of refcounted objects inside C++ lambdas in Gecko) tl;dr: We should make Di

Re: Intent to deprecate: Insecure HTTP

northrupthebandg...@gmail.com schrieb: On Monday, April 13, 2015 at 8:26:59 PM UTC-7, ipar...@gmail.com wrote: * Less scary warnings about self-signed certificates (i.e. treat HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with HTTPS+selfsigned now); the fact that self-si

Re: Intent to deprecate: Insecure HTTP

Yoav Weiss schrieb: IMO, limiting new features to HTTPS only, when there's no real security reason behind it will only end up limiting feature adoption. It directly "punishing" developers and adds friction to using new features, but only influence business in a very indirect manner. That's my c

Re: Intent to deprecate: Insecure HTTP

northrupthebandg...@gmail.com schrieb: That whole article is just additional shovelfuls of bovine manure slopped onto the existing heap. Please refrain from language like that in lists like this if you want to be taken seriously. KaiRo ___ dev-pl

Re: Intent to deprecate: Insecure HTTP

vic schrieb: I would view this proposal favorably if 1) you didn't try to force people to adopt the One True Way and 2) the CA situation was fixed. Please define of what alternatives to what you call the "One True Way" are acceptable to you and still secure to access, and also what specific

Re: Intent to deprecate: Insecure HTTP

Boris Zbarsky schrieb: On 4/14/15 3:28 AM, Anne van Kesteren wrote: On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost wrote: 1. You do not need to register a domain name to have a Web site (IP address) Name one site you visit regularly that doesn't have a domain name. My router's configuration

Re: Intent to deprecate: Insecure HTTP

On 2015-04-15 10:03 AM, commodorej...@gmail.com wrote: On Wednesday, April 15, 2015 at 6:56:48 AM UTC-7, Joseph Lorenzo Hall wrote: If you're addicted to cleartrext, the future is going to be hard for you... Only because people like you insist on trying to push it across-the-board, rather than

Re: Intent to deprecate: Insecure HTTP

On Wed, Apr 15, 2015 at 10:03 AM, wrote: > rather than let webmasters make their own decisions. I firmly disagree with your conclusion, but I think you have identified the central property that is changing. Traditionally transport security has been a unilateral decision of the content provid

Re: Intent to deprecate: Insecure HTTP

On Wednesday, April 15, 2015 at 6:56:48 AM UTC-7, Joseph Lorenzo Hall wrote: > If you're addicted to cleartrext, the future is going to be hard for you... Only because people like you insist on trying to push it across-the-board, rather than let webmasters make their own decisions. ___

Re: Intent to deprecate: Insecure HTTP

If you're addicted to cleartrext, the future is going to be hard for you... On Tue, Apr 14, 2015 at 2:26 PM, wrote: > HTTPS has its moments, but the majority of the web does not need it. I > certainly wouldn't appreciate the encryption overhead just for visiting > David's lolcats website. As o

Intent to implement and ship `AudioBufferSourceNode.detune`

Summary: This new attribute allows authors to modulate the `.playbackRate` property of the AudioBufferSourceNode in cents (which is a scale that is more useful in a musical context, because logarithmic instead of linear). This also aligns the AudioBufferSourceNodes with other source nodes, that pre

Re: Intent to deprecate: Insecure HTTP

On Wed, Apr 15, 2015 at 12:10 PM, Gervase Markham wrote: > 2) Reduced privacy. And that's why the connection would be marked as > insecure in the UI. We need to move away from HTTPS being able to go into an insecure state. We can't expect the user to keep an eye on the address bar the whole time.

Re: Intent to deprecate: Insecure HTTP

On 15/04/15 10:59, Anne van Kesteren wrote: > HTTPS already has mixed content, we should not make it worse. What's actually wrong with mixed content? 1) The risk of content tampering. Subresource integrity makes that risk go away. 2) Reduced privacy. And that's why the connection would be marked

Re: Intent to deprecate: Insecure HTTP

On Wed, Apr 15, 2015 at 11:50 AM, Gervase Markham wrote: > Radical idea: currently, the web has two states, insecure and secure. > What if it still had two states, with the same UI, but insecure meant > "HTTPS top-level, but some resources may be loaded using HTTP with > integrity", and secure mea

Re: Intent to deprecate: Insecure HTTP

On 14/04/15 17:46, j...@chromium.org wrote: > I just wanted to mention that regarding subresource integrity > (https://w3c.github.io/webappsec/specs/subresourceintegrity/), the > general consensus over here is that we will not treat origins as > secure if they are over HTTP but loaded with integrit

Re: Intent to deprecate: Insecure HTTP

On 14/04/15 16:39, david.a.p.ll...@gmail.com wrote: > >> There are already multiple sources of free publicly-trusted certificates, >> with more on the way. >> https://www.startssl.com/ >> https://buy.wosign.com/free/ >> https://blog.cloudflare.com/introducing-universal-ssl/ >> https://letsencrypt.

Re: Intent to deprecate: Insecure HTTP

On 14/04/15 22:59, northrupthebandg...@gmail.com wrote: > The article assumes that when folks connect to something via SSH and > something changes - causing MITM-attack warnings and a refusal to > connect - folks default to just removing the existing entry in > ~/.ssh/known_hosts without actually q

Re: nsIStreamConverter & e10s

Yes, the platform bug seems to be related. I commented in the report. Honza > On 10 Apr 2015, at 18:11, Gabor Krizsanits wrote: > > I'm working on a bug that might be related > (https://bugzilla.mozilla.org/show_bug.cgi?id=982319 > ). Coul

Re: Intent to deprecate: Insecure HTTP

On 14/04/15 13:32, Eric Shepherd wrote: > My main concern with the notion of phasing out unsecured HTTP is that > doing so will cripple or eliminate Internet access by older devices that > aren't generally capable of handling encryption and decryption on such a > massive scale in real time. > > Wh

RE: changing the default platform and operating-system on bugzilla.mozilla.org to all / all

+1 to suggestions from Lawrence and Milan. The info is still pretty important for the QA team, and we definitely do NOT want it gone. Regards, Florin. -Original Message- From: dev-platform [mailto:dev-platform-bounces+florin.mezei=softvisioninc...@lists.mozilla.org ] On Behalf Of Byron Jo

PSA: mochitest is() now uses ===

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Bug 949614 landed yesterday, making the is() function in mochitests compare its argument with === rather than ==. is_loosely() has been introduced (hopefully temporarily) with is()'s old behaviour; ise() is now simply an alias for is(). Thank