On Thu, Nov 8, 2012 at 6:56 PM, Ehsan Akhgari wrote:
> On 2012-11-08 1:44 AM, Henri Sivonen wrote:
>> 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.
>
> Hmm, well, a partial feature might be cons
On Thu, Nov 8, 2012 at 5:47 PM, Benoit Jacob wrote:
> That's a theoretical problem only so far: in practive, since the
> un-prefixed extension generally behaves exactly like the prefixed one,
> websites have been good at trying getting both and using whatever they
> get.
In other words, prefixing
On 11/08/12 12:46, richardson.balca...@gmail.com wrote:
I was just reading the effort of installing "open web apps" locally, I'm
assuming the strategy shift that I'm talking about is that Mozilla is betting on Firefox
as their application framework, that would make sense not to support Xulrunn
On 11/8/2012 10:19 PM, Kyle Huey wrote:
On Thu, Nov 8, 2012 at 12:52 PM, Honza Bambas wrote:
Few reasons:
- I really don't believe we will soon/ever have a good OOP Firefox
implementation
- content JS execution very often kills my Firefox UI (and it is not I/O
that blocks)
- sync APIs like loca
On Thu, Nov 8, 2012 at 12:52 PM, Honza Bambas wrote:
> Few reasons:
> - I really don't believe we will soon/ever have a good OOP Firefox
> implementation
> - content JS execution very often kills my Firefox UI (and it is not I/O
> that blocks)
> - sync APIs like localStorage would not block the UI
Few reasons:
- I really don't believe we will soon/ever have a good OOP Firefox
implementation
- content JS execution very often kills my Firefox UI (and it is not I/O
that blocks)
- sync APIs like localStorage would not block the UI
- content JS GC would stop blocking UI as well
- generally wo
I was just reading the effort of installing "open web apps" locally, I'm
assuming the strategy shift that I'm talking about is that Mozilla is betting
on Firefox as their application framework, that would make sense not to support
Xulrunner anymore.
I would like to see how could one use the n
On 11/8/2012 2:06 PM, richardson.balca...@gmail.com wrote:
> I believe my question is, if Mozilla is taking out their app development
> platform not 'XUL' per se. How would they promote "openness, innovation and
> opportunity on the web", only by giving us the opportunity of doing so in
> extens
On 11/8/2012 2:20 PM, Honza Bambas wrote:
If a test runner doesn't currently support
resource://testing-common/, please file a bug and let's get it
implemented everywhere.
Alternatively, I suppose we could hack up the "main" manifest file to
include resource://testing-common if ENABLE_TESTS i
On 11/8/2012 8:10 PM, Gregory Szorc wrote:
On 11/8/12 11:04 AM, Honza Bambas wrote:
On 11/8/2012 12:26 AM, Benjamin Smedberg wrote:
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
I believe my question is, if Mozilla is taking out their app development
platform not 'XUL' per se. How would they promote "openness, innovation and
opportunity on the web", only by giving us the opportunity of doing so in
extensions on a browser?
What's the strategy? Is not clear where is this
On 11/8/12 11:04 AM, Honza Bambas wrote:
On 11/8/2012 12:26 AM, Benjamin Smedberg wrote:
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
On 11/8/2012 12:26 AM, Benjamin Smedberg wrote:
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
El miércoles, 7 de noviembre de 2012 15:28:58 UTC-4, Dave Townsend escribió:
>
> > 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
On 11/07/2012 02:03 PM, Henri Sivonen wrote:
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. T
On 2012-11-08 1:44 AM, Henri Sivonen wrote:
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 rele
2012/11/8 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 exte
On Wed, Nov 7, 2012 at 4:13 PM, James Graham wrote:
> There is an experimental branch with this mode in; it isn't production
> quality yet. I am still unsure that it's a good idea; in particular I think
> it encourages people to write multiple tests on the same page in such a way
> that if one fai
18 matches
Mail list logo