Thanks Kris for all this information and the beginning of the first issue
of this newsletter!
2018-07-10 20:19 GMT+02:00 Kris Maglione :
> The problem is thus: In order for site isolation to work, we need to be
> able to run *at least* 100 content processes in an average Firefox session
I've see
Hi,
Sorry, arriving a bit late to the party.
I was about to propose something related to @@toStringTag, but reading the
discussions about how it may/will work [1][2][3], i realize it may not be your
preferred solution.
Maybe @@toStringTag will end up not working well enough for your need anyway
Hi Boris,
Did a particular feature triggered your message?
Would it make sense to add the question to the "Intent to Implement" email
template?
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement
"Intent to" emails seem like a good time to ask this questions/raise:
* the feat
Le mardi 27 septembre 2016 14:49:36 UTC+2, David Teller a écrit :
> I have opened bug 1305669 with one possible strategy for migrating
> towards RequireJS.
RequireJS [1] is a peculiar choice for chrome code especially if your goal is
static analysis.
From this thread and what I read in bug, it d
Le lundi 18 juillet 2016 20:57:12 UTC+2, Gregory Szorc a écrit :
> On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote:
>
> We already have deterministic packaging in some parts of Firefox (notably
> most XPIs and omni.ja files). We've done this by implementing our own
> jar
Hi,
Two recent comments on the Linux reproducible build bug thread [1] suggest that
the bug has no clear end goal.
In this email, I'll try to describe what I understand of the problem and
discuss the outline of a possible end goal.
I felt that the topic covers a wide enough range of responsibil
Hi,
Just a drive-by comment to inform folks that there is an effort to
transition Mozilla JavaScript codebase to standard JavaScript.
Main bugs is: https://bugzilla.mozilla.org/show_bug.cgi?id=867617
And https://bugzilla.mozilla.org/show_bug.cgi?id=1103158 is about
removing non-standard featu
Hi Paolo,
The ES6 iterator protocol is what you're looking for. See:
*
https://hacks.mozilla.org/2015/04/es6-in-depth-iterators-and-the-for-of-loop/
*
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator
Alongside with the computed property syntax,
Le mercredi 19 février 2014 13:43:57 UTC+1, apransk...@gmail.com a écrit :
> We need to debug and measure execution time of JavaScript inside the pages we
> display.
For this sort of work, web developers tend to use PhantomJS or CasperJS
nowadays.
http://phantomjs.org/
http://casperjs.org/ (buil
Hi,
So far, nobody said that the idea was either stupid or impossible/impractical,
so I went ahead and filed https://bugzilla.mozilla.org/show_bug.cgi?id=961689
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.or
Le jeudi 16 janvier 2014 18:31:59 UTC+1, Boris Zbarsky a écrit :
> It's pretty far away in Gecko as it stands, because we have all sorts of
> global state (class statics, say!) that is not parallel-safe.
>
> Process-separated is likely to be simpler to get to work without pesky
> things like mem
Hi,
Machines are getting more cores, web devs want to make use of that opportunity.
We (webdev hat) have WebWorkers, that's cool, but one can only do ~math in
there. It's not possible to update a UI in real time from a WebWorker. It's not
possible to update a canvas or WebGL context either. New
Hi,
(I'm not 100% sure this is the proper mailing list to ask this question, but I
can't think of a more relevant mailing-list at this time. Please forward if
inappropriate)
After a long period of reluctance, Mozilla is deciding to implement WebP
[1][2]. The only explanation I have been able t
Le 03/04/2013 22:12, Andrew Overholt a écrit :
Yesterday a number of people discussed future plans for the WebAPI
team. Our discussion resulted in the ideas and comments that are on
this wiki page:
https://wiki.mozilla.org/WebAPI/PlannedWork
There is a little item near the end, "tests". Wha
14 matches
Mail list logo