On 2012-11-08 1:44 AM, Henri Sivonen wrote:
On Thu, Nov 8, 2012 at 12:03 AM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
On 11/07/2012 02:03 PM, Henri Sivonen wrote:
On Wed, Oct 10, 2012 at 10:46 AM, Aryeh Gregor a...@aryeh.name 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
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/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
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/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 is
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
extensions
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
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
On Thu, Nov 8, 2012 at 12:52 PM, Honza Bambas hbam...@mozilla.com 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
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
On Thu, Nov 8, 2012 at 5:47 PM, Benoit Jacob jacob.benoi...@gmail.com 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
On Thu, Nov 8, 2012 at 6:56 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
13 matches
Mail list logo
