Re: Intent to implement: Metrics API for FxOS data collection

Tamara Hills writes: > Summary: We want to expose a Web API to Gaia to collect metrics for FxOS. > This API would leverage the existing Gecko toolkit/components/telemetry > capabilities to provide histograms to Telemetry Servers for analysis by > data owners. This is interesting. I wanted to do

Re: Intent to deprecate: Insecure HTTP

On 01/05/15 19:02, Matthew Phillips wrote: > You must have missed my original email: > It's paramount that the web remain a frictionless place where creating a > website is dead simple. That is not true today of people who want to run their own hosting. So people who want "frictionless" use blogs

Re: Intent to deprecate: Insecure HTTP

On 03/05/15 03:39, Xidorn Quan wrote: > This has been happening in the Internet in China. I would suggest you use > "360 Secure Browser", one of the major browsers in China. They completely > consider the experience of developers and users. Their browser allows user > to access a website even if th

Re: Intent to deprecate: Insecure HTTP

On 01/05/15 20:40, Eric Shepherd wrote: > In my case, the situation is that I have classic computers running 1-10 > megahertz processors, for which encrypting and decrypting SSL is not a > plausible option. For this edge case, I would say the solution is to use a proxy, run on one of your other (f

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 10:04 PM, Gervase Markham wrote: > On 03/05/15 03:39, Xidorn Quan wrote: > > This has been happening in the Internet in China. I would suggest you use > > "360 Secure Browser", one of the major browsers in China. They completely > > consider the experience of developers and

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 1:25 AM, Richard Barnes wrote: > 3. HTTP caching is an important feature for constrained networks. I think it important to emphasize that the affected case is shared caching in the form of forward proxies. https doesn't prevent caching in the browser or caching on site-chos

Re: Intent to deprecate: Insecure HTTP

On Sat, May 2, 2015 at 11:57 AM, Nicholas Nethercote wrote: > Please refrain from further discussion until you can avoid making > crude personal attacks such as these. > I now mandate that you (and everyone you know) shall only do ethernet trough pigeon carriers. There are great advantages to doi

Re: Intent to deprecate: Insecure HTTP

On 5/2/15 05:25, Florian Bösch wrote: I now mandate that you (and everyone you know) shall only do ethernet trough pigeon carriers. There are great advantages to doing this, and I can recommend a number of first rate pigeon breeders which will sell you pigeons bred for that purpose. I will not

Re: Intent to deprecate: Insecure HTTP

On 2015-05-04 8:37 AM, Henri Sivonen wrote: I think without empirical evidence showing the *current* (as opposed to arguments from 20 years ago) importance of shared caching on the supposed "constrained networks"--i.e. empirical evidence showing that the shared cache hit rate is is a make-or-bre

Re: Intent to deprecate: Insecure HTTP

On Monday, May 4, 2015 at 9:40:08 AM UTC-4, Adam Roach wrote: > On 5/2/15 05:25, Florian Bösch wrote: > > I now mandate that you (and everyone you know) shall only do ethernet > > trough pigeon carriers. There are great advantages to doing this, and > > I can recommend a number of first rate pige

No more binary components in extensions

(Followup questions or comments to mozilla.dev.extensions only, please.) With the landing of bug 1159737, I have removed support for binary XPCOM components in extensions. This is planned to ride the Firefox 40 train. This change is necessary because we no longer expose or intend to expose a

Re: No more binary components in extensions

Benjamin Smedberg wrote: I will be updating MDN documentation and removing or archiving old documentation about binary XPCOM components in the next few weeks. Please ping me before outright deleting anything; I'd like to be sure we're able to continue to support people embedding Gecko or target

Re: Intent to deprecate: Insecure HTTP

On 5/4/15 11:24, Florian Bösch wrote: On Mon, May 4, 2015 at 3:38 PM, Adam Roach > wrote: others who want to work for a better future A client of mine whom I polled if they can move to HTTPs with their server stated they do not have the time and resources to do so.

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 6:33 PM, Adam Roach wrote: > You have made some well-thought-out contributions to conversations at > Mozilla in the past. I'm a little sad that you're choosing not to > participate in a useful way here. > I think this is a pretty relevant contribution. Obviously it's not

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 3:38 PM, Adam Roach wrote: > others who want to work for a better future > A client of mine whom I polled if they can move to HTTPs with their server stated they do not have the time and resources to do so. So the fullscreen button will just stop working. That's an amazing

Re: Intent to deprecate: Insecure HTTP

I agree HTTPS makes information safer and protects it¹s integrity, making it (once again) safer. However; 1) are the benefits worth the millions of man-hours, and countless dollars this will cost? 2) why is Mozilla suddenly everyone¹s nanny? - Shawn On 5/1/15, 2:44 PM, "Joseph Lorenzo Hall" wro

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 9:39 AM, Florian Bösch wrote: > On Mon, May 4, 2015 at 6:33 PM, Adam Roach wrote: > > > You have made some well-thought-out contributions to conversations at > > Mozilla in the past. I'm a little sad that you're choosing not to > > participate in a useful way here. > > >

Re: W3C Proposed Recommendation: HTML5 Web Messaging

On Wednesday 2015-04-08 17:03 -0700, L. David Baron wrote: > W3C recently published the following proposed recommendation (the > stage before W3C's final stage, Recommendation): > > HTML5 Web Messaging > http://www.w3.org/TR/webmessaging/ > > There's a call for review to W3C member companies

Re: Intent to deprecate: Insecure HTTP

On 05/04/2015 09:39 AM, Florian Bösch wrote: > Here is what I wrote that client: > > [...] For security reasons browsers want to disable fullscreen if you >> are not serving the website over HTTPS. Are you sure this is true? Where has it been proposed to completely disable fullscreen for non-HTT

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert wrote: > (I think there's a strong case for disabling *persistent* fullscreen > permission, for the reasons described in ekr's response to you here. I > haven't seen any proposal for going beyond that, but I might've missed it.) A little birdy told

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 10:52 AM, Florian Bösch wrote: > On Mon, May 4, 2015 at 7:43 PM, Eric Rescorla wrote: > >> This would be more useful if you explained what they considered the cost >> of converting to HTTPS so, so we could discuss ways to ameliorate that cost. >> > I agree. But I don't get

Re: what is new in talos, what is coming up

The upcoming changes sound great! Is there currently a way (or plans to add a way) to track regressions / improvements for a single measurement within a test? I see that in perfherder I can add these measurements to a graph (http://mzl.la/1E17Zyo ) but it’s hard to disti

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla wrote: > > I'm going to refer you at this point to the W3C HTML design principles of > priority of constituencies > (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies). > > "In case of conflict, consider users over authors over im

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 12:59 PM, Florian Bösch wrote: > On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla wrote: >> >> I'm going to refer you at this point to the W3C HTML design principles of >> priority of constituencies >> (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies >

Re: Intent to deprecate: Insecure HTTP

On Tue, May 5, 2015 at 6:04 AM, Martin Thomson wrote: > On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert > wrote: > > (I think there's a strong case for disabling *persistent* fullscreen > > permission, for the reasons described in ekr's response to you here. I > > haven't seen any proposal for

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 1:57 PM, Xidorn Quan wrote: > On Tue, May 5, 2015 at 6:04 AM, Martin Thomson wrote: > > > On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert > > wrote: > > > (I think there's a strong case for disabling *persistent* fullscreen > > > permission, for the reasons described in e

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

Wait - you're telling me that it is now possible to limit try pushes but not just jobs but tests within jobs?! Stop the presses: this is huge! If used by the masses, this could drastically reduce try turnaround times and decrease automation load and costs. Could we encourage use of --tag by having

Re: Intent to deprecate: Insecure HTTP

We're adding UX to clearly indicate http:// or https:// in fullscreen while still meeting the user desire for secure one-click-to-fullscreen. The latest and greatest proposal posted here: https://bugzilla.mozilla.org/show_bug.cgi?id=1129061 --Jet On Mon, May 4, 2015 at 2:04 PM, Eric Rescorla wr

Re: Intent to deprecate: Insecure HTTP

Great! Without getting too deep into the exact details about animation / notifications / permissions, it sounds like Florian's concern RE "browsers want to disable fullscreen if you are not serving the website over HTTPS" may be unfounded, then. (Unless Florian or Martin have some extra informati

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

Sounds great! I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1161282 for this. According to https://secure.pub.build.mozilla.org/builddata/reports/reportor/daily/highscores/highscores.html, we still have a ton of people using '-p all -u all' on try On Mon, May 4, 2015 at 5:12 PM, Gregory

Is there an e10s plan for multiple content processes?

Inquiring minds would like to know. At the moment, e10s tabs is still somewhat slower than non-e10s. Multiple content processes would go a long way for more responsive navigation and less stalls on the one content process. That stall spinner is getting a LOT of hate at the moment. ___

Re: No more binary components in extensions

On 5/4/15 6:07 PM, Eric Shepherd wrote: > Benjamin Smedberg wrote: >> I will be updating MDN documentation and removing or archiving old >> documentation about binary XPCOM components in the next few weeks. > Please ping me before outright deleting anything; I'd like to be sure > we're able to con

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

On Thursday, April 30, 2015 at 7:22:26 PM UTC-4, Christopher Manchester wrote: > You can now add "--tag" arguments to try syntax and they will get passed to > test harnesses in your try push. Details of the implementation are in bug > 978846, but if you're interested in passing other arguments from

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

That looks like a valid use of the feature assuming the manifest was annotated correctly. I'm not sure what went wrong, I'll reply here when I figure out what went wrong or file a bug and investigate further. Chris On Mon, May 4, 2015 at 4:23 PM, wrote: > On Thursday, April 30, 2015 at 7:22:26

Re: No more binary components in extensions

The patch in the bug removes it from the shared manifest parser, Thunderbird and SeaMonkey are out of luck unless they fork this. -Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

It looks like I inadvertently landed this change on an the wrong branch, so we aren't pointing to it in production (although we were for a short time when I tested last week). I'll straighten this out in the morning. Sorry for the inconvenience. Chris On Mon, May 4, 2015 at 4:43 PM, Christopher M

Re: No more binary components in extensions

The patch in the bug isn't going to work anyway because we still need binary components for b2g, so no panic needed on the TB/SM side. On Mon, May 4, 2015 at 5:22 PM, Daniel Veditz wrote: > The patch in the bug removes it from the shared manifest parser, > Thunderbird and SeaMonkey are out of lu

Re: No more binary components in extensions

On Mon, May 04, 2015 at 06:06:21PM -0700, Bobby Holley wrote: > The patch in the bug isn't going to work anyway because we still need > binary components for b2g, so no panic needed on the TB/SM side. The patch in the bug doesn't disable *application* binary components, it disables *extensions* bi

Re: No more binary components in extensions

On 05/05/2015 08:22, Daniel Veditz wrote: > The patch in the bug removes it from the shared manifest parser, > Thunderbird and SeaMonkey are out of luck unless they fork this. -Dan > Veditz That sounds rather drastic. How does one fork only this feature without forking the whole of mozilla-centra

Re: Is there an e10s plan for multiple content processes?

On Tue, May 5, 2015 at 10:29 AM, Leman Bennett (Omega X) < Redacted.For.Spam@request.contact> wrote: > Inquiring minds would like to know. > > At the moment, e10s tabs is still somewhat slower than non-e10s. Multiple > content processes would go a long way for more responsive navigation and > less

Re: Is there an e10s plan for multiple content processes?

On 5/5/2015 12:23 AM, Robert O'Callahan wrote: On Tue, May 5, 2015 at 10:29 AM, Leman Bennett (Omega X) < Redacted.For.Spam@request.contact> wrote: Inquiring minds would like to know. At the moment, e10s tabs is still somewhat slower than non-e10s. Multiple content processes would go a long wa