Re: What platform features can we kill?

On 2013-10-10 12:56 PM, Brian Smith wrote: On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit wrote: 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. ... Considering t

Re: interest in having Mozilla officially represented at the C++ Standards Committee?

On 10/10/2013 11:22 AM, Botond Ballo wrote: Is there any interest in having Mozilla be officially represented at the C++ Standards Committee? I actually asked about this a couple months ago (with the goal of being one of the representatives). I'm glad to see there's some more traction on this

Re: interest in having Mozilla officially represented at the C++ Standards Committee?

> > At this stage, I'm just looking to assess the level of > > interest from our C++ developers. If there is interest, I > > will look into the processes involved in more detail. > > I think we have enough interesting uses of C++ that it is in our > interest to participate. In terms of time commit

Re: java click to run problem on Firefox

On 10/10/2013 3:46 PM, Thierry Milard wrote: Benjamin, here is my description of the java Plugin activation issue I do have. * * *1) Warning sign not displayd upper left when applet is in the middle* The "No entry sign" is displaid on the upper left of the html page, not placed where my java p

[Planned Maintenance Notification] - Tree Closure, 2013-10-12 @ 1200 PDT

All trees closed Saturday, Oct 12, from 12:00-16:30 PDT Original Message Subject:[Planned Maintenance Notification] - Tree Closure, 2013-10-12 @ 1200 PDT Date: Thu, 10 Oct 2013 13:51:48 -0700 From: Mozilla IT Operations To: every...@mozilla.org Short Summary

Re: interest in having Mozilla officially represented at the C++ Standards Committee?

On 10/10/13 4:21 PM, Botond Ballo wrote: At this stage, I'm just looking to assess the level of interest from our C++ developers. If there is interest, I will look into the processes involved in more detail. I think we have enough interesting uses of C++ that it is in our interest to particip

Re: java click to run problem on Firefox

On 2013-10-10 4:47 PM, Henri Sivonen wrote: On Oct 10, 2013 7:26 PM, "Adam Roach" wrote: [java source] --javac-> [java bytecode] --llvm-> [llvm bitcode] --emscripten-> [javascript] Or easier: [java source] --GWT-> [javascript] Adam asked specifically about the Emscripten case, which is wha

Re: java click to run problem on Firefox

On Oct 10, 2013 7:26 PM, "Adam Roach" wrote: > [java source] --javac-> [java bytecode] --llvm-> [llvm bitcode] --emscripten-> [javascript] Or easier: [java source] --GWT-> [javascript] ___ dev-platform mailing list dev-platform@lists.mozilla.org https:

Re: java click to run problem on Firefox

On 10/10/13 14:42, Ehsan Akhgari wrote: There is a java compiler that targets llvm somewhere which I can't find a link to right now, but it's unmaintained and IIRC it did not cover all of the Java syntax. But the real problem is in the huge API set that the JVM provides for various platform se

Re: java click to run problem on Firefox

On Thu, Oct 10, 2013 at 9:42 PM, Ehsan Akhgari wrote: >> Has anyone here played around with the toolchain I describe above? > > I have looked into this briefly. There is a java compiler that targets llvm > somewhere which I can't find a link to right now, but it's unmaintained and > IIRC it did n

Re: Migrating to Win64 rev2 machines

Project branches are cutting over to the new win64-rev2 build machines. John On 13-10-09 5:22 PM, John Hopkins wrote: > Release Engineering is migrating the Windows 64-bit _build_ machines to > a new, managed machine image which will decrease the amount of > administrative overhead needed to dep

Re: interest in having Mozilla officially represented at the C++ Standards Committee?

> I think this is a great idea, unless there are severe > financial/contractual obligations! The cost of participating in committee meetings is simply that of sending someone to attend them. They are 1 week long, and happen 2-3 times a year in locations that rotate between North America and Europe

Re: interest in having Mozilla officially represented at the C++ Standards Committee?

I think this is a great idea, unless there are severe financial/contractual obligations! Cheers, Ehsan On 2013-10-10 12:22 PM, Botond Ballo wrote: Hi everyone, Judging by the responses to my thread [1] about the C++ Standards Committee meeting a couple of weeks ago, there seems to be a fair b

Re: java click to run problem on Firefox

Being the "firefox person" who suggested that Thierry should discuss this on dev-platform, let me chime in. I seem to understand that Thierry's issue is partially related to the fact that the UX of his site was designed with the assumption that if Java didn't start, then Java either wasn't install

Re: unified shader for layer rendering

Vlad put in a "let's see if we can cache compiled shaders" bug in a few weeks ago, and perhaps that is something we should consider when discussing shaders in general. I didn't know about recompiling when some uniforms change though, that's good intel. -- - Milan On 2013-10-10, at 15:13 , Jeff

Re: unified shader for layer rendering

I didn't see anything in this message that suggested "we should drop everything we're doing and start on this right now", but most of the early comments I'm seeing are commenting on that. Let's make that a separate discussion. If we didn't have all these variations, what would we do? Would we

Re: java click to run problem on Firefox

On 2013-10-10 12:25 PM, Adam Roach wrote: On 10/10/13 11:09, Benjamin Smedberg wrote: We encourage you to transition your site away from Java as soon as possible. If there are APIs which you need in the web platform in order to make that possible, please let me know and we will try to make addin

Re: What platform features can we kill?

On Thu 10 Oct 2013 10:07:53 AM PDT, Till Schneidereit wrote: > 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-interne

Re: unified shader for layer rendering

I'll also add a note that just because we aren't recompiling doesn't mean the driver isn't. If we change enough (or maybe just the correct) uniforms, this can cause the driver to recompile the shader, which is indeed slow. Trying to unify too many shader types might just tickle this. Some drive

Re: unified shader for layer rendering

I do appreciate the fact that it reduces complexity (in addition to less state changes). I agree that the decision of dedicating resources on that rather than on other high priority projects that are in the pipes should be motivated by some numbers. Cheers, Nical On Thu, Oct 10, 2013 at 11:0

Re: unified shader for layer rendering

2013/10/10 Benoit Jacob > I'll pile on what Benoit G said --- this is the kind of work that would > require very careful performance measurements before we commit to it. > > Also, like Benoit said, we have seen no indication that glUseProgram is > hurting us. General GPU "wisdom" is that switchin

Re: unified shader for layer rendering

I'll pile on what Benoit G said --- this is the kind of work that would require very careful performance measurements before we commit to it. Also, like Benoit said, we have seen no indication that glUseProgram is hurting us. General GPU "wisdom" is that switching programs is not per se expensive

Re: Solving cross-origin script problem ("permission denied") when using custom protocol handler

On 10/10/13 1:06 PM, Matthew Gertner wrote: Yes. Not sure if it's relevant but the remote script (and some of the local scripts) are loaded using RequireJS, which means that the

Re: Solving cross-origin script problem ("permission denied") when using custom protocol handler

On Thursday, October 10, 2013 6:58:24 PM UTC+2, Boris Zbarsky wrote: > That's ... quite odd. Scripts loaded via a

Re: java click to run problem on Firefox

On 10/10/13 12:06, Thierry Milard wrote: There are still a few things like speedy 3D That html-javascipt do bot do Dell enough http://www.unrealengine.com/html5/ -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev

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: java click to run problem on Firefox

Adam, I AM NOT anytime soon Young to change to javascript. There are still a few things like speedy 3D That html-javascipt do bot do Dell enough... Yet. Maybe in 3 Yeats I wiki transition ... -Message d'origine- De : Adam Roach Envoyé : 10/10/2013 18:25 À : Benjamin Smedberg; Thierry Mil

Re: Solving cross-origin script problem ("permission denied") when using custom protocol handler

On 10/10/13 12:43 PM, Matthew Gertner wrote: This page loads script both from the local disk (using the same protocol handler) and remote script loaded via HTTPS. When I try to access properties on objects instantiated in the remote script from my local script, I get "permission denied" errors.

Re: What platform features can we kill?

On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit wrote: > 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 surf

Re: unified shader for layer rendering

On Thu, Oct 10, 2013 at 7:59 AM, Andreas Gal wrote: > Rationale: > switching shaders tends to be expensive. > In my opinion this is the only argument for working on this at moment. Particularly at the moment where we're overwhelmed with high priority desktop and mobile graphics work, I'd like to

Solving cross-origin script problem ("permission denied") when using custom protocol handler

I have a page in my extension loaded from my own protocol handler. This page loads script both from the local disk (using the same protocol handler) and remote script loaded via HTTPS. When I try to access properties on objects instantiated in the remote script from my local script, I get "permi

Re: java click to run problem on Firefox

On 10/10/13 11:09, Benjamin Smedberg wrote: We encourage you to transition your site away from Java as soon as possible. If there are APIs which you need in the web platform in order to make that possible, please let me know and we will try to make adding those a priority. I haven't personall

Re: Extensibility of JavaScript modules

Don't hesitate to ping me when it's time. Cheers, David On 10/10/13 12:04 AM, Jason Orendorff wrote: > On 10/9/13 12:56 PM, David Rajchenbach-Teller wrote: >> I am interested, although my buglist is rather full. What kind of help >> would be useful? > > When it's time, we'll need to: > > 1. wr

interest in having Mozilla officially represented at the C++ Standards Committee?

Hi everyone, Judging by the responses to my thread [1] about the C++ Standards Committee meeting a couple of weeks ago, there seems to be a fair bit of interest in the standardization of some new C++ language features and libraries. A lot of the committee members are engineers at companies with

Re: java click to run problem on Firefox

On 10/10/2013 11:44 AM, Thierry Milard wrote: I have a java "Web application" (www.free-visit.net). the way Mozilla manages the java player is ... killing my users experience : they have not choce to go to chrome, because I can not do otherwyse : java won'y run even f they have the latest-of-the-

Re: Poll: What do you need in MXR/DXR?

> Better python support. For example, the function name parameter doesn't work > with ext: .py > > http://dxr.mozilla.org/mozilla-central/search?q=function%3Astart%20ext%3A.py > <-- no results > http://dxr.mozilla.org/mozilla-central/search?q=%22def%20start%22%20ext%3A.py > <-- results To clar

java click to run problem on Firefox

Hello, This is my first post on dev-platform at mozilla so please if my question is not from here please just tell me. The guys from Firefox told me to go here Subject : (java blocked) + (Click to run java) usabillity bug(?) I have a java "Web application" (www.free-visit.net). the way Mozill

Re: What platform features can we kill?

On 10/10/13 10:28 AM, Axel Hecht wrote: My point is, the perf was completely abysmal, and the key is to use nsINodeInfo for the xpath patterns instead of DOM localName and namespaceURI string comparisons. This may still be an issue, though I wouldn't be surprised if the speed of .localName in

Re: What platform features can we kill?

On 10/10/13 15:28, Axel Hecht wrote: On 10/10/13 2:43 PM, Jeff Walden wrote: On 10/10/2013 02:27 PM, Axel Hecht wrote: I agree with the sentiment, but not on the eample. Having been a peer of the XSLT module back in the days, we started with a rather js DOM like implementation, and moved over

Re: What platform features can we kill?

On 10/10/13 2:43 PM, Jeff Walden wrote: On 10/10/2013 02:27 PM, Axel Hecht wrote: I agree with the sentiment, but not on the eample. Having been a peer of the XSLT module back in the days, we started with a rather js DOM like implementation, and moved over to a pure nsIContent etc impl, and e

Re: What platform features can we kill?

Maybe not quite platform features, but on the subject of removing or js replacements, I offer up a couple of candidates: http://mxr.mozilla.org/comm-central/source/mozilla/xpfe/components/directory/ I believe this is an rdf datasource for listing ftp directory pages. AFAIK this might only be used

Re: Migrating to Win64 rev2 machines

Yes, we have. +vlad On 2013-10-09 7:35 PM, Kyle Huey wrote: > Did we start caring about Win64 again recently? > > +bsmedberg > > - Kyle > > > On Wed, Oct 9, 2013 at 7:33 PM, Jet Villegas wrote: > >> Excellent. >> >> Now to find willing volunteer(s.) Windows 64 represents a key platform for

Re: What platform features can we kill?

On 10/10/13 2:54 AM, Chris Peterson wrote: The meta bug for removing JSD is bug 800200. I believe the primary blocking issue is bug 716647 ("allow Debugger to be enabled with debuggee frames on the stack"), which jorendorff is starting to work on. Well, I tried it a year and a half ago. jandem

Re: What platform features can we kill?

On 2013-10-09 11:18 PM, Nicholas Nethercote wrote: * XSLT We also use it for about:memory apparently. We do? Can you show me where? Sorry, my bad, I meant to say addons manager: ___

Re: What platform features can we kill?

On 10/10/2013 02:27 PM, Axel Hecht wrote: > I agree with the sentiment, but not on the eample. > > Having been a peer of the XSLT module back in the days, we started with a > rather js DOM like implementation, and moved over to a pure nsIContent etc > impl, and each step there won us an order of

Re: What platform features can we kill?

On 10/10/13 2:36 AM, Zack Weinberg wrote: On 2013-10-09 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? In between "keep the C++ implementation" and "scrap entirely" is "reimplement in JS", and I think that should be seriously considered

unified shader for layer rendering

Hi, we currently have a zoo of shaders to render layers: RGBALayerProgramType, BGRALayerProgramType, RGBXLayerProgramType, BGRXLayerProgramType, RGBARectLayerProgramType, RGBXRectLayerProgramType, BGRARectLayerProgramType, RGBAExternalLayerProgramType, ColorLayerProgramType, Y

How to Instantiate JavaScript XPCOM Component from C++ XPCOM Component

Hi Could you please help me " Instantiate JavaScript XPCOM Component from C++ XPCOM Component/ C++ Code" I have tried one same code given below. HellowWorld.js Components.utils.import("resource://gre/modules/XPCOMUtils.jsm"); function HelloWorld() { } H

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: Migrating to Win64 rev2 machines

it takes a lot of work to get green tests on a new platform. I spent the better part of December to March getting tests green on Ubuntu. If these are in vms, we wouldn't have the graphics cards mentioned above. In fact we might not have the ability to run the webgl tests. _

Re: What platform features can we kill?

On 10/10/13 00:28, Philipp Kewisch wrote: > So you are saying, we should start removing features that could decrease > the attack surface? ...and that we don't need. What I'm saying is: perhaps feature-ectomies (and driving the web or our code to a position where we can make them) may be higher p

Re: What platform features can we kill?

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 after image format has died on the vine because it wasn't *enough* of a

Re: Master Password (was Re: What platform features can we kill?)

On 10 October 2013 10:22:13, Michael Lefevre wrote: I wouldn't disagree with any of the other reasons, but could you clarify what you mean when you say the cryptography is useless? FireMaster seems to just brute force passwords. Are you just saying that any cryptography that relies on a password

Re: Master Password (was Re: What platform features can we kill?)

On 10/10/2013 11:22, Michael Lefevre wrote: Master password. The UI is prone to phishing, it causes all sorts of problems because of how we use the log in to the NSS database to implement it, it causes annoying UX for the people that use it, the cryptography used is useless (bing FireMaster), the

Master Password (was Re: What platform features can we kill?)

On 09/10/2013 22:00, Brian Smith wrote: On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham wrote: Attack surface reduction works: http://blog.gerv.net/2013/10/attack-surface-reduction-works/ In the spirit of learning from this, what's next on the chopping block? Master password. The UI is prone

Re: What platform features can we kill?

On Wed, Oct 9, 2013 at 6:01 PM, Gervase Markham wrote: > * XSLT (Chrome have already announced they will remove it: > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0 > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k8aIeI6BCG0 What I watched Adam des

Re: What platform features can we kill?

On Wed, Oct 9, 2013 at 9:12 PM, Mike Hommey wrote: >> At the summit a few of us were talking about ways to promote Rust. >> One idea was to rewrite a smallish, well-separated component of >> Firefox in Rust, to (a) gain the benefits (parallelism, safety) of >> Rust, and (b) promote Rust as a credi

Re: What platform features can we kill?

On 10/9/13 8:18 PM, Nicholas Nethercote wrote: On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgari wrote: > >In the spirit of learning from this, what's next on the chopping block? JSD. Firebug's the main consumer, AFAIK. The meta bug for removing JSD is bug 800200. I believe the primary blocki