Re: Proposal: Not shipping prefixed APIs on the release channel

2012-11-07 Thread Henri Sivonen
On Thu, Nov 8, 2012 at 8:41 AM, Henri Sivonen wrote: > However, it is considered important that we not reneg on a promise > already made in the WebGL WG, I would rather exclude WebGL from what I > proposed than keep proliferating prefixes in other APIs. However, *if* it is… -- Henri Sivonen hsi

Re: Proposal: Not shipping prefixed APIs on the release channel

2012-11-07 Thread Henri Sivonen
On Thu, Nov 8, 2012 at 12:03 AM, Ehsan Akhgari wrote: > How does this proposal address the question of partially implemented > features? If we consider a partial feature ready for use by Web developers, then we could ship the partial feature on the release channel without prefix. > Do we need to

Re: Proposal: Not shipping prefixed APIs on the release channel

2012-11-07 Thread Henri Sivonen
On Wed, Nov 7, 2012 at 8:11 PM, Benoit Jacob wrote: > My concrete example is WebGL extensions. These go through 4 stages: > 1. "proposal": no browser must implement it. > 2. "draft": implementations must use a vendor prefix. I think stage 2 is a bug to the extent stage 2 reaches the release cha

Re: Proposal: Not shipping prefixed APIs on the release channel

2012-11-07 Thread Henri Sivonen
On Wed, Nov 7, 2012 at 7:24 PM, Joe Drew wrote: > On 2012-11-06 8:31 AM, Henri Sivonen wrote: >> >> Therefore, I propose that we adopt the following policy: >> 1) APIs that are not ready for use by Web developers shall not be >> shipped on the release channel (unless preffed off). >> 2) APIs t

gonk, cups, printing from firefox os

2012-11-07 Thread Gary Weaver
I noticed in the manifest description that there is no way to access a print device: https://developer.mozilla.org/en-US/docs/Apps/Manifest A number of apps are available in Android that allow printing, not just cloud printing but the ability to use CUPS, etc. I know that Gonk is mostly hands-o

Re: Shipping a component as part of the test package

2012-11-07 Thread Benjamin Smedberg
On 11/7/12 12:00 PM, Honza Bambas wrote: Hi all. I'd like to ask for help. tl;dr: a new JS component needs to be accessible by xpcshell and mochitest, how to do that? It's not clear to me why this needs to be a component. Since we already have testing-only modules working, can this just be a

Re: Shipping a component as part of the test package

2012-11-07 Thread Gregory Szorc
On 11/7/12 2:17 PM, Honza Bambas wrote: Those are modules, also as Joshua pointed out. I want a component that *not* tests will use, but test-*harness* will use. I hope it will work with tests! I would love to switch Sync's unit tests over to TLS if I could. We currently use httpd.js as an im

Re: Shipping a component as part of the test package

2012-11-07 Thread Honza Bambas
On 11/7/2012 9:03 PM, Bobby Holley wrote: We have some XPConnect test components in js/xpconnect/tests/components that might be instructive. Cheers, bholley Those are modules, also as Joshua pointed out. I want a component that *not* tests will use, but test-*harness* will use. We already h

Re: Shipping a component as part of the test package

2012-11-07 Thread Kyle Huey
On Wed, Nov 7, 2012 at 12:00 PM, Honza Bambas wrote: > Hi all. I'd like to ask for help. > > tl;dr: a new JS component needs to be accessible by xpcshell and > mochitest, how to do that? > > > Details: > I'm introducing a new JS implemented component that is used to control > ssltunnel (a part o

Re: Shipping a component as part of the test package

2012-11-07 Thread Gregory Szorc
On 11/7/12 1:56 PM, Joshua Cranmer wrote: On 11/7/2012 2:00 PM, Honza Bambas wrote: Hi all. I'd like to ask for help. tl;dr: a new JS component needs to be accessible by xpcshell and mochitest, how to do that? We have test-only modules already; how hard would it be to add test-only component

Re: Proposal: Not shipping prefixed APIs on the release channel

2012-11-07 Thread Ehsan Akhgari
How does this proposal address the question of partially implemented features? Do we need to implement everything in the spec to be able to ship something on the release channel? Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org http

Re: Shipping a component as part of the test package

2012-11-07 Thread Joshua Cranmer
On 11/7/2012 2:00 PM, Honza Bambas wrote: Hi all. I'd like to ask for help. tl;dr: a new JS component needs to be accessible by xpcshell and mochitest, how to do that? We have test-only modules already; how hard would it be to add test-only components to our build system? _

Slight change to performance vs. memory tradeoff in style system

2012-11-07 Thread L. David Baron
I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=572200 on mozilla-inbound, which makes a slight change to a performance vs. memory tradeoff in the style system. In particular, in cases where we cache style data in the rule tree, this causes us to cache the data on any rule nodes that ar

Re: Shipping a component as part of the test package

2012-11-07 Thread Bobby Holley
We have some XPConnect test components in js/xpconnect/tests/components that might be instructive. Cheers, bholley On Wed, Nov 7, 2012 at 12:00 PM, Honza Bambas wrote: > Hi all. I'd like to ask for help. > > tl;dr: a new JS component needs to be accessible by xpcshell and > mochitest, how to

Shipping a component as part of the test package

2012-11-07 Thread Honza Bambas
Hi all. I'd like to ask for help. tl;dr: a new JS component needs to be accessible by xpcshell and mochitest, how to do that? Details: I'm introducing a new JS implemented component that is used to control ssltunnel (a part of our testing infrastructure). I want test harnesses use it. H

Telemetry dashboards - temporary outage

2012-11-07 Thread deinspanjer
At about 11 AM Pacific, a database server that supports the Telemetry dashboards started suffering severe performance problems. We were able to work with IT to rectify the issue, but during that time, the site was unavailable. It has just been brought back online. Please let us know on #metri

Re: XULRunner on OS X, Why is not supported?

2012-11-07 Thread Dave Townsend
On 11/06/12 13:58, richardson.balca...@gmail.com wrote: At first I tried for a couple of days to try to get xulrunner 16.0.2 to work on my OSX 10.6, until I understoo it wasn't working at all running the 'xulrunner -v' will return an 'error' string where the version should come out. Looking in

Re: Proposal: Not shipping prefixed APIs on the release channel

2012-11-07 Thread Benoit Jacob
I support the principle here but I want to make sure that we don't hurt ourselves by applying good principles more strictly than our competition. My concrete example is WebGL extensions. These go through 4 stages: 1. "proposal": no browser must implement it. 2. "draft": implementations must use

Re: Proposal: Not shipping prefixed APIs on the release channel

2012-11-07 Thread Joe Drew
On 2012-11-06 8:31 AM, Henri Sivonen wrote: Therefore, I propose that we adopt the following policy: 1) APIs that are not ready for use by Web developers shall not be shipped on the release channel (unless preffed off). 2) APIs that are shipped on the release channel shall be shipped without

Re: XULRunner on OS X, Why is not supported?

2012-11-07 Thread passfree
Hi Richard, I would love to get more support for xulrunner given that I have already spent 3 year on xulrunner-based application but I am getting none. My advice is to stay away from it. It is clear that Mozilla is not taking this product anywhere. If you like to do stuff in Markup and Javascri

Re: Proposed policy change: reusability of tests by other browsers

2012-11-07 Thread Henri Sivonen
On Wed, Oct 10, 2012 at 10:46 AM, Aryeh Gregor wrote: > That said, of course, Mozilla hackers *are* familiar with Mochitest > but not testharness.js, and adopting testharness.js in parallel with > Mochitest would require people to be familiar with both. That is > certainly a minus. I was told at