Re: Intent to ship: Hashbang syntax in JS (a "#!" line at the very start of a script is a single-line comment)

Thank you for doing this! It's a minor, but real, source of potential web-compat issues, so it's nice to have it handled. On Thu, Feb 28, 2019 at 11:00 PM Jeff Walden wrote: > ## Support in other browser / JS engines > > https://github.com/v8/v8/commit/0cd67eb7c57e109aa4cbc8b8bdff6b9eaf8c1286 >

Re: Intent to ship: BigInt

On Thu, Feb 21, 2019 at 9:56 AM L. David Baron wrote: > On Thursday 2019-02-21 15:44 +0100, Andy Wingo wrote: > > ## Support in other browser / JS engines > > > > Chrome / V8 implements the draft spec. > > > > Safari / JavaScriptCore has a partial implementation that is being > > completed on an

Re: Dead-code removal of unused Rust FFI exports

CC'ing mw, who is working on cross-language LTO. On Tue, Aug 28, 2018 at 3:20 PM Mike Hommey wrote: > On Tue, Aug 28, 2018 at 09:14:02AM -0400, Jeff Muizelaar wrote: > > We don't LTO yet on Mac. > > We don't LTO across languages on any platform yet. Rust is LTOed on all > platforms, which remove

Re: Firefox and clang-cl

On Mon, Aug 14, 2017 at 9:27 AM, Julian Seward wrote: > On 13/08/17 03:40, Ehsan Akhgari wrote: > > As you may have heard by now, Chromium has started to switch their > Windows > > builds to use clang-cl instead of MSVC [1]. This has improved their > > Speedometer v2 benchmark score on x86 (but

Re: Async Iteration is available on non-release-only, for testing purpose

I think disabling in chrome code is a good idea. We have done these kinds of non-release-only features in the JS engine in the past, and it hasn't always gone well precisely for the reasons that have you concerned. OTOH, adding a pref is annoyingly complicated for JS engine features (we should prob

Re: Switching to async/await from Task.jsm/yield

On Sun, Mar 26, 2017 at 8:16 PM, Ehsan Akhgari wrote: > On 2017-03-17 7:41 PM, Kris Maglione wrote: > > On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote: > >> Have we measured the performance of our async/await implementation? I > >> think we should definitely do some extensive test

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Tue, Feb 14, 2017 at 12:00 PM, 段垚 wrote: > > > 在 2017/2/14 18:10, Till Schneidereit 写道: > >> On Tue, Feb 14, 2017 at 12:14 AM, 段垚 wrote: >> >> I guess all popular softwares have exploits being traded. How this fact >>> >>>> invalidates my a

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Tue, Feb 14, 2017 at 12:14 AM, 段垚 wrote: > I guess all popular softwares have exploits being traded. How this fact >>> invalidates my argument? >>> >> I was responding to your point about the threat declining because of the >> declining usage of Flash. This is demonstrably not true. >> > > Wh

Re: Intent to disable service workers and push in 52 ESR

On Wed, Jan 18, 2017 at 5:43 PM, Ben Kelly wrote: > On Wed, Jan 18, 2017 at 10:58 AM, Till Schneidereit < > t...@tillschneidereit.net> wrote: > >> That'll mean that Windows XP/Vista users won't have them. >> >> Might be ok, but means the bar for a deci

Re: Intent to disable service workers and push in 52 ESR

That'll mean that Windows XP/Vista users won't have them. Might be ok, but means the bar for a decision like this should be somewhat higher than usual, I think. On Wed, Jan 18, 2017 at 4:49 PM, Ben Kelly wrote: > Hi all, > > I'd like to disable service workers in 52 ESR. This would also requir

Re: Tamarin

ActionScript. I was looking at asm.js > and it does use a strict subset of javascript.Also Emscripten and I do > have Unreal 4. > > On Fri, Aug 12, 2016 at 8:21 AM, Till Schneidereit > wrote: > > On Fri, Aug 12, 2016 at 1:45 PM, Jonathan Moore > wrote: > >&

Re: Tamarin

the ActionScript VM is in maintenance mode there, too. > > All the best, > > Jonathan. > > On Fri, Aug 12, 2016 at 5:03 AM, Till Schneidereit > wrote: > > Hi Jonathan, > > > > first, I'll strongly recommend that you take a look at WebAssembly as a > > pos

Re: Tamarin

Hi Jonathan, first, I'll strongly recommend that you take a look at WebAssembly as a possible alternative to what you're trying to do. It'll be integrated into the web platform more and more over the coming years, and might just satisfy your needs. That being said, you can find the Tamarin source

Re: the looming wasm chasm was Re: Requiring SSE2 on all 32-bit x86 OSs

On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser wrote: > On 5/18/16 10:41 PM, Jan de Mooij wrote: > >> They do get the baseline compiler, which can still be significantly >>> faster than the interpreter, but Ion requires SSE2. Since the runtime >>> detection does just turn Ion off altogether, I

Re: help:browser tool box debugger is not stopped

On Mon, Apr 25, 2016 at 8:41 AM, oonuma ryouyu wrote: > I think this is not bug. > Or normally firefox memorized breakpoints before restart? > You're right: breakpoints aren't remembered across restarts, so that part isn't a bug. The breakpoint being ignored, however, is a bug. Have you made sur

Re: An analysis of content process memory overhead

I filed bug 876173[1] about this a long time ago. Recently, I talked to Gabor, who's started looking into enabling multiple content processes. One other thing we should be able to do is sharing the self-hosting compartment as we do between runtimes within a process. It's not that big, but it's not

Re: any concerns with dropping the talos test v8 and using AWFY Octane instead?

On Mon, Jan 11, 2016 at 3:08 PM, wrote: > Currently we run a very outdated version of V8 (version 7) in Talos. This > has since been replaced with Octane in the world of benchmarks. > > AWFY (arewefastyet.com), has been running Octane and catching regressions > faster than Talos. There is missi

Re: Dan Stillman's concerns about Extension Signing

On Thu, Nov 26, 2015 at 10:02 AM, Thomas Zimmermann wrote: > Am 25.11.2015 um 20:16 schrieb Jeff Gilbert: > > On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit > > wrote: > >> FWIW, I received questions about this via private email and phone calls > >> from

Re: Dan Stillman's concerns about Extension Signing

FWIW, I received questions about this via private email and phone calls from two people working on extensions that support their products. Their extensions sit in the review queue with not chance of getting through it before the signing requirement kicks in. This puts them into a situation where th

Re: Is that possible to implement Sqlite.jsm with ctypes so that is can works in the worker?

On Fri, Nov 20, 2015 at 12:23 PM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > It could be improved a bit, but the real issue is that JavaScript is a > high-level, garbage-collected, dynamic programming language, while C is > a low-level, memory-unsafe, type-unsafe, statically compiled

Re: Decreasing quality?

On Wed, Aug 19, 2015 at 3:18 AM, Gavin Sharp wrote: > It's possible this bug was being confused with bug 1195030. > That seems likely, yes. Being responsible for this particular regression, I can say that neither is it at all related to the other bugs mentioned, nor can it reasonably be interpre

Re: Array.concat

On Tue, Jul 21, 2015 at 12:19 PM, Mike de Boer wrote: > Hi Amit, > > These are called ‘Generics’ and are available in Firefox as of JavaScript > 1.6 - see > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods > < > https://developer.mozilla

Re: The e10s throbber

On Tue, Apr 7, 2015 at 5:05 PM, Bill McCloskey wrote: > I think we probably want to use a longer delay than 300ms before we show > the spinner. We'd also like to look into why it takes so long to re-create > the layer tree when we switch to a tab. Sometimes it's caused by a janky > content proces

Re: Enhancing Gecko as a WebGL game platform

On Tue, Jan 13, 2015 at 8:24 PM, Luke Wagner wrote: > > Do you know what they actually mean when they use the term "hardware > > pointer"? > > > > I believe what he's referring to is the type of hardware-accelerated cursor > support discussed here: > > > http://technet.microsoft.com/en-us/magazin

Re: Array.prototype.includes available in Nightly *only* & String.prototype.contains renamed to includes

I don't know :/. Perhaps Jason does? > > / Jonas > > On Fri, Nov 21, 2014 at 5:10 AM, Till Schneidereit > wrote: > > Greetings! > > > > TC39 has decided to solve the web-compat issues with > > Array.prototype.contains that forced us to back out

Re: Array.prototype.includes available in Nightly *only* & String.prototype.contains renamed to includes

On Fri, Nov 21, 2014 at 2:54 PM, Dao wrote: > On 21.11.2014 14:10, Till Schneidereit wrote: > >> Greetings! >> >> TC39 has decided to solve the web-compat issues with >> Array.prototype.contains that forced us to back out the feature on October >> 1st by ren

Array.prototype.includes available in Nightly *only* & String.prototype.contains renamed to includes

Greetings! TC39 has decided to solve the web-compat issues with Array.prototype.contains that forced us to back out the feature on October 1st by renaming the method to "includes". This has now landed on Nightly. However, it is Nightly-only for now, so don't use it in production code that's intend

Re: PSA: Array.prototype.contains is going away again

On Thu, Oct 2, 2014 at 4:51 PM, Ehsan Akhgari wrote: > On 2014-10-02, 9:58 AM, Till Schneidereit wrote: The full answer to that is actually ridiculously complicated. The part >> relevant here is, though: very early on in at least some cases. Too >> early to rely on preferen

Re: PSA: Array.prototype.contains is going away again

On Wed, Oct 1, 2014 at 7:51 PM, Ehsan Akhgari wrote: > On 2014-10-01, 1:20 PM, Till Schneidereit wrote: > >> That's a great point. It would be great if we can adopt >> https://wiki.mozilla.org/WebAPI/ExposureGuidelines for new JS >> fatures as well. &g

Re: PSA: Array.prototype.contains is going away again

On Thu, Oct 2, 2014 at 2:24 PM, Philip Chee wrote: > On 02/10/2014 17:30, David Rajchenbach-Teller wrote: > > On 02/10/14 10:49, James Graham wrote: > >> Unfortunately js libraries aren't like web browsers; you can't just ship > >> a new version and upgrade all existing users in a matter of weeks

Re: PSA: Array.prototype.contains is going away again

> > That's a great point. It would be great if we can adopt > https://wiki.mozilla.org/WebAPI/ExposureGuidelines for new JS fatures as > well. > Yes, I think we should consider that. The situation is somewhat different in that we usually only implement features that are stable, specced, and agree

PSA: Array.prototype.contains is going away again

Unfortunately, it turns out that Array.prototype.contains breaks the web. Or, the MooTools-using parts of the web, at least. So I'm preparing a backout right now. What's more pressingly unfortunate is that Array.prototype.contains enjoys a surprisingly spectacular popularity: it's already used in

Re: easiest way to contribute .

On Thu, Sep 25, 2014 at 9:45 PM, Mike Hoye wrote: > This page: https://developer.mozilla.org/en-US/docs/Introduction > > ... has some good information about getting your development environment > set up so you can contribute to Firefox. > And so does this: http://codefirefox.com/ ___

Re: Intent to implement: "image-rendering: pixelated" CSS property-value

On Wed, Sep 24, 2014 at 7:21 PM, Daniel Holbert wrote: > On 09/24/2014 07:38 AM, Ehsan Akhgari wrote: > >> This makes the implementation considerably simpler, which is great. It > >> also means that "pixelated" will essentially just be a > >> more-interoperable version of "-moz-crisp-edges", for

Re: Review Board Preview

On Mon, Sep 15, 2014 at 4:40 PM, Mark Côté wrote: > Yes, we plan on supporting more than just mozilla-central. The initial > deployment will only support Mercurial, but we plan on adding git > support soon after--and there's no reason it couldn't work with GitHub > as well. > That's great to he

Re: Review Board Preview

I agree with Ehsan: this is really exciting! Do you also plan to add integration with external repositories at a later point? I'm working on the Shumway project, and we do our bug tracking in BMO, but have our source in github (largely for historical reasons, but a reason for not moving away from

Re: What are the most important new APIs to document in Q3/Q4?

Some ES6 features would be great to have documentation for. Symbols and Template Strings come to mind, both of which have recently landed at least partially. On Fri, Jun 27, 2014 at 6:03 AM, Eric Shepherd wrote: > On 2014-06-26 23:07:40 +, Brian Birtles said: > > I hope to land parts of th

Re: C++ standards proposals of potential interest, and upcoming committee meeting

On Wed, Jun 11, 2014 at 12:55 AM, Jeff Gilbert wrote: > > What's the core problem trying to be solved here? It's either: > A) We want a 2D graphics API in C++. > or > B) We want to make it easy to do 2D graphic in C++. > > The reason it feels like B implies A is that using libraries is a terrible

Re: C++ standards proposals of potential interest, and upcoming committee meeting

On Mon, Jun 9, 2014 at 9:45 PM, Benoit Jacob wrote: > I would like the C++ committee's attention to be drawn to the dangers, for > committee, to try to make decisions outside of its domain of expertise. I > see more potential for harm than for good in having the C++ committee join > the ranks of n

Re: Google announces Chrome builds for Win64

On Thu, Jun 5, 2014 at 2:36 PM, Philip Chee wrote: > On 04/06/2014 22:32, jmor...@mozilla.com wrote: > > > We have a good understanding of the work required. The development > > work, as you might suspect, is largely done. We still produce 64 bit > > builds. The notable areas remaining are: > > >

Re: Intent to implement: DOMMatrix

On Wed, Jun 4, 2014 at 1:17 AM, Rik Cabanier wrote: > > > > On Tue, Jun 3, 2014 at 3:48 PM, Till Schneidereit < > t...@tillschneidereit.net> wrote: > >> On Wed, Jun 4, 2014 at 12:26 AM, Rik Cabanier wrote: >> >>> > Actually, inverse() is alread

Re: Intent to implement: DOMMatrix

On Wed, Jun 4, 2014 at 12:26 AM, Rik Cabanier wrote: > > Actually, inverse() is already spec'd to throw if the inversion fails. In > > that case (assuming we keep it that way) there is no need at all for any > > isInvertible kind of method. Note that in floating-point arithmetic there > > is no a

Re: Standardized assertion methods

Should we adopt these for SpiderMonkey's test suites, too? Porting tests between suites isn't something that's done frequently, but there are people writing tests for more than one suite, and being able to use the same assertion methods everywhere would be helpful for that. On Mon, Jun 2, 2014 at

Re: Policing dead/zombie code in m-c

(CC'ing people who have worked on the ICU integration) On Thu, Apr 24, 2014 at 2:31 PM, Henri Sivonen wrote: > However, especially in the context of slimming down our own set of > encoding converters, it's rather demotivating to see that at least on > desktop, we are building ICU encoding conver

Re: Using rr to track down intermittent test failures

On Wed, Apr 16, 2014 at 1:52 AM, Ehsan Akhgari wrote: > On 2014-04-15, 7:14 PM, Gijs Kruitbosch wrote: > >> On 16/04/2014 00:05, Robert O'Callahan wrote: >> >>> We just released rr 1.2 and I think this would be a good time for >>> people to >>> try to use it for one of the tasks it was designed fo

Re: We live in a memory-constrained world

On Sat, Feb 22, 2014 at 2:31 PM, Kyle Huey wrote: > On Fri, Feb 21, 2014 at 5:28 PM, Till Schneidereit > wrote: > > Does that mean that bug 964057[1] will automatically cause all > self-hosting > > state to be shared amongst content processes, too? > > > >

Re: We live in a memory-constrained world

Does that mean that bug 964057[1] will automatically cause all self-hosting state to be shared amongst content processes, too? [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=964057 On Sat, Feb 22, 2014 at 2:12 PM, Kyle Huey wrote: > On Fri, Feb 21, 2014 at 5:07 PM, Jason Duell > wrote: > >

Re: Wasted bytes due to padding (bug 492185)

On Fri, Feb 21, 2014 at 7:15 AM, Gabriele Svelto wrote: > On 20/02/2014 18:57, arpad.bor...@googlemail.com wrote: > > And yes, allocation counts would be awesome. Any idea how to get to > those? Or even better: number of average live objects, since short lived > allocations do not matter that much

Re: Individual files should have a reviewer reference

On Fri, Feb 14, 2014 at 10:35 AM, Nick Alexander wrote: > On 2/13/2014, 1:23 PM, Honza Bambas wrote: > >> An optional /* @reviewer: m...@foo.com */ comment under the license would >> do. If not present, find reviewer the usual way (not always hitting the >> right person). >> > > -1 from me on any

Re: Cairo being considered as the basis of a standard C++ drawing API

On Mon, Feb 10, 2014 at 12:00 PM, Brian Smith wrote: > On Sun, Feb 9, 2014 at 2:54 PM, Robert O'Callahan > wrote: > > On Mon, Feb 10, 2014 at 11:49 AM, Brian Smith > wrote: > >> It seems likely that if something like Moz2D became the standard API > then > >> we'd be able to optimize it more eas

Re: Intent to ship DOM Promises

On Wed, Jan 29, 2014 at 9:07 PM, wrote: > On Wednesday, January 29, 2014 10:35:24 AM UTC-8, Nikhil Marathe wrote: > > As off January 28, our DOM Promises implementation implements the es6 > > > > promises spec. [1] > > > > It is feature complete, and passes the Promises/A+ tests. [2] > > > > I in

Re: Terminating xulrunner?

Hi Gio, please read the previous messages in this thread: they contain answers to all these questions. In fact, they're pretty much all answered right in the first message[1]. [1]: https://groups.google.com/d/msg/mozilla.dev.platform/o99wQZBjIJw/4eBoWbjEzjAJ On Tue, Jan 21, 2014 at 7:02 AM, wr

Re: using LLDB to debug Gecko

This is fantastic, thank you so much! a few months ago, I started looking into porting the pretty printers and niceties for various SpiderMonkey things that live in js/src/gdb, but the way much of this works is very different from gdb, so I didn't get too far back them. This makes me want to pick

Re: Decommissioning "dumbmake"

On Thu, Jan 16, 2014 at 6:05 PM, Ted Mielczarek wrote: > On 1/16/2014 11:26 AM, Till Schneidereit wrote: > > > > I'd be extremely unhappy if this disappeared without any replacement. > > Changing a cpp file under js/src and running `mach` takes about 2 minutes > &g

Re: Decommissioning "dumbmake"

(Some messages in this thread seem to be taking an absurdly long time to arrive, so I apologize if what I'm talking about has long been addressed.) On Thu, Jan 16, 2014 at 2:00 PM, Philip Chee wrote: > On 15/01/2014 02:37, Matt Brubeck wrote: > > On 1/13/2014 8:05 PM, Mike Hommey wrote: > >> I

Re: JavaScript Style Guide. Emacs mode line.

On Wed, Jan 8, 2014 at 9:25 AM, ishikawa wrote: > BTW, do java or javascript programmers use Eclipse with its built-in editor > with suitable editor configuration, > and that is the end of the story for such Eclipse users when they tinker > with Mozilla source code? > I use Eclipse for working o

Re: Bug 641509

My point is that your arguments have been brought forward in the discussion, and your post didn't bring anything new to the table. You might disagree with the decision the contributors and owners of the affected module have come to, and that's your right. Snide remarks and shooting down exaggerate

Re: Bug 641509

The discussion has happened in bug 588292[1]. For a succinct summary, see tha bug's comment 37[2]. For the reasoning behind restricting comments, see that bug's comment 116[3] In general, it's very unlikely that a basic point as the one you made wasn't considered in a discussion spanning 230 comme

Re: On the usefulness of style guides (Was: style guide proposal)

> moz.build option that autoformatted or checked against the general > formatting rules, then that might be sufficient. I think that bug 939350 > shows a template for that. > > - Original Message - > From: "Bobby Holley" > To: "Martin Thomson&qu

Re: style guide proposal

On Thu, Dec 19, 2013 at 5:02 PM, Ehsan Akhgari wrote: > -- > Ehsan > > > > On Thu, Dec 19, 2013 at 4:32 AM, Mike Hommey wrote: > > How about we just use clang-format? > > http://www.irill.org/videos/euro-llvm-2013/jasper-hires.webm > > > clang-format has a basic suppor

Re: [RFC] Cleaning up sessionstore.js

On Thu, Nov 28, 2013 at 1:55 PM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > On 11/28/13 1:33 PM, Till Schneidereit wrote: > > This would all be tackled after we did other things like getting rid > > of all history entries for iframes, which won't be resto

Re: [RFC] Cleaning up sessionstore.js

On Thu, Nov 28, 2013 at 11:56 AM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > As many of you know, Session Restore is something of a performance hog, > for many reasons – we have reports of. One of the reasons is that we > store so very many things in sessionstore.js and sometimes kee

Re: W3C Proposed Recommendations: Performance Timeline, User Timing, JSON-LD

I don't know how well (or if at all) the current push for performance devtools is coordinated with these proposals, but it would certainly be worth looking into that. CCing Axel Kratel. On Tue, Nov 26, 2013 at 12:31 AM, Boris Zbarsky wrote: > On 11/25/13 7:07 PM, L. David Baron wrote: > >>

Re: Intent to replace Promise.jsm and promise.js with DOM Promises

On Wed, Nov 20, 2013 at 4:04 PM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > On 11/20/13 1:09 PM, Till Schneidereit wrote: > > How about logging them with console.info? That seems the right logging > > level to me, and it's easy to turn off if it gets

Re: Intent to replace Promise.jsm and promise.js with DOM Promises

On Wed, Nov 20, 2013 at 12:51 PM, Anne van Kesteren wrote: > On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky wrote: > > We could report all rejections, but I'm a bit leery of adding so much > noise > > that people start ignoring the report altogether; a common problem in the > > past. > > Given th

Re: Pushes to Backouts on Mozilla Inbound

On Tue, Nov 5, 2013 at 4:09 PM, Ed Morley wrote: > On 05 November 2013 14:44:27, David Burns wrote: > >> We appear to be doing 1 backout for every 15 pushes on a rough >> average[4]. >> > > I've been thinking about this some more - and I believe the ratio is > probably actually even worse than th

Re: Mozilla development "bootcamp"

On Mon, Nov 4, 2013 at 10:44 AM, Gijs Kruitbosch wrote: > On 04/11/13, 10:30 , Neil wrote: > >> Gijs Kruitbosch wrote: >> >> On 03/11/13, 11:46 , Neil wrote: >>> >>> 14. Rebasing a bitrotted patch > 14.0 What it looks like when you qpush a patch that has conflics > 14.1 Open a rej file

Re: Mozilla development "bootcamp"

On Sun, Nov 3, 2013 at 11:07 PM, wrote: > On Sunday, November 3, 2013 12:02:15 PM UTC-5, Alexandre BM wrote: > > I see a lot of VS and .exes, any plans for development on Unix ? (make, > > gcc, gdb, g* tools ?) > > ~ rednaks > > Yes these are just starting videos, but I was planning to have linux

Re: Synchronous workers

On Mon, Oct 14, 2013 at 11:31 PM, Robert O'Callahan wrote: > On Mon, Oct 14, 2013 at 4:29 PM, Till Schneidereit > wrote: >> >> From talking to Kyle, it sounds like getting WebGL into workers is >> much closer than getting all of Context2D, too. Specifically, we n

Re: Synchronous workers

On Mon, Oct 14, 2013 at 10:16 PM, Benjamin Smedberg wrote: > On 10/14/2013 4:12 PM, Robert O'Callahan wrote: > >> On Mon, Oct 14, 2013 at 11:03 AM, Benjamin Smedberg > > wrote: >> >> Having this blocking interface will also support blocking shumway >> on graph

Re: Synchronous workers

On Mon, Oct 14, 2013 at 6:30 PM, Bobby Holley wrote: > On Mon, Oct 14, 2013 at 6:21 PM, Till Schneidereit wrote: >> Nobody's proposing to expose any of this to web content. The question is >> whether we want to fully expose it as an official capability of Gecko, to be >&

Re: Synchronous workers

Didn't see this before now, sorry. On Mon, Oct 14, 2013 at 6:15 PM, Benjamin Smedberg wrote: > On 10/14/2013 12:06 PM, Bobby Holley wrote: >> >> How common are the blocking API calls? > > Expect them to be very common or almost universal for "real" Flash. Much > less common for simple display ads

Re: Synchronous workers

- Original Message - > How common are the blocking API calls? Can we somehow predict whether > the SWF will need that, and optionally use a worker/non-worker context > based on that? Fairly common: many SWFs use ExternalInterface at least once, and even more use BitmapData#draw, which all

Re: What platform features can we kill?

On Thu, Oct 10, 2013 at 6:56 PM, Brian Smith wrote: > I'm not sure. Things like this seem like really good ideas: > http://blogs.msdn.com/b/ie/archive/2013/09/12/using-hardware-to-decode-and-load-jpg-images-up-to-45-faster-in-internet-explorer-11.aspx > > Obviously, I am linking to somewhat of an

Re: What platform features can we kill?

On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto wrote: > On 10/10/2013 02:36, Zack Weinberg wrote: >> >> In that vein, I think we should take a hard look at the image decoders. >> Not only is that a significant chunk of attack surface, it is a place >> where it's hard to innovate; image format a

Re: Extensibility of JavaScript modules

Interesting. I wonder if the monkey patching will even still work once we have es6 modules and use them in the platform. Jason and Eddy, you probably know, but I'm under the impression that monkey patching an es6 module requires funneling it through a custom module loader. Maybe the platform shoul

Re: Implementing Pepper since Google is dropping NPAPI for good

On Tue, Sep 24, 2013 at 5:19 PM, Zack Weinberg wrote: > On 2013-09-23 4:29 PM, Hubert Figuière wrote: > >> PS: I truly believe that we should drop plugin support all together, but >> that's not what I'm discussing here. >> > > I think if we think our options going forward are "implement PPAPI" an

Re: Bugzilla Secure Mail Viewer for GMail now on AMO

This is fantastic, thank you *so* much! On Wed, Jul 3, 2013 at 7:40 PM, bent wrote: > Hi folks, > > I've finally uploaded my secure mail viewer addon to AMO so that updates > will work someday soon. Here's the link: > > > https://addons.mozilla.org/en-US/firefox/addon/bugzilla-secure-mail-viewe

Re: Best way to make xpcshell provide consistent stack limits?

On Sat, Jun 29, 2013 at 12:52 AM, Benjamin Smedberg wrote: > On 6/26/13 7:06 PM, Andrew Sutherland wrote: > >> >> >> d) Change xpconnect to use jsnativestack.cpp's ability to tell us what >> the platform stack size actually is and/or nsThread's knowledge of the >> stack size it was created with.

Re: Best way to make xpcshell provide consistent stack limits?

Thanks for bringing this up. I agree that we should do something about this, and if only for testing purposes. I would tend to favor g) Add a command line argument to set the stack quota to the lowest any of our platforms support. That way, you can be sure that your script really does run on all

Re: Proposal to make Firefox open in the foreground on Mac when launched from terminal

Oh yes, please, a thousand times yes! On Thu, May 30, 2013 at 12:09 AM, Ehsan Akhgari wrote: > Typically when you use the terminal to open an application on Mac, the > application is opened in the background. This means that for example when > you use mach run or mach debug, you need to either

Re: Rethinking the amount of system JS we use in Gecko on B2G

On Thu, Apr 25, 2013 at 7:41 AM, Caspy7 wrote: > I'm not a developer and so apologize if my understanding is oversimplified > or naive. > I had been under the impression that C++ (previously) was not being used > at all, apart from Gecko itself, for security and stability reasons. > Perhaps I am

Re: Accelerating exact rooting work

There's a rooting guide on the wiki here: https://developer.mozilla.org/en-US/docs/SpiderMonkey/GC_Rooting_Guide It's not very thorough, but it's something. On Tue, Apr 23, 2013 at 3:14 PM, Tom Schuster wrote: > You wont have to bother with HandleObject or RootedObject etc. These > are interna

Re: Rethinking the amount of system JS we use in Gecko on B2G

On Mon, Apr 22, 2013 at 9:48 PM, Justin Lebar wrote: > > This is all great stuff, but as mentioned elsewhere, B2G branched at > > version 18 and so they need improvements that that can land quickly on > > the relevant branches. > I understand that (but should certainly have made it more clear).

Re: Rethinking the amount of system JS we use in Gecko on B2G

There are a few things we're working on in SpiderMonkey that should improve this situation quite a bit: Terrence already mentioned generational GC, which certainly is the largest piece by far. Getting rid of all or almost all memory lost to fragmentation makes the tradeoff a considerably different

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 4:42 PM, Ehsan Akhgari wrote: > On 2013-01-31 10:33 AM, Till Schneidereit wrote: >>>> >>>> In the long run, 1 and 3 are the same. If we know we're going to turn >>>> it off, why not bite the bullet and do it now? >>>

Re: The future of PGO on Windows

>> In the long run, 1 and 3 are the same. If we know we're going to turn >> it off, why not bite the bullet and do it now? > > > > Because we're still missing plenty of optimizations in our code > to be fast in microbenchmarks. It would be quite huge pr loss if we suddenly > were 10-20% slower in