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
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
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
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
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
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
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
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
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
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
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
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?
_
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo