On 10/9/13 8:18 PM, Nicholas Nethercote wrote:
On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgariehsan.akhg...@gmail.com 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
On Wed, Oct 9, 2013 at 9:12 PM, Mike Hommey m...@glandium.org 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
On Wed, Oct 9, 2013 at 6:01 PM, Gervase Markham g...@mozilla.org 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
On 09/10/2013 22:00, Brian Smith wrote:
On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham g...@mozilla.org 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
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),
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
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
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
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.
On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto gsve...@mozilla.com 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;
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()
{
}
Hi,
we currently have a zoo of shaders to render layers:
RGBALayerProgramType,
BGRALayerProgramType,
RGBXLayerProgramType,
BGRXLayerProgramType,
RGBARectLayerProgramType,
RGBXRectLayerProgramType,
BGRARectLayerProgramType,
RGBAExternalLayerProgramType,
ColorLayerProgramType,
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 for
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
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:
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/updateinfo.xsl?force=1
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
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
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
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
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
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 Mozilla
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 clarify,
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
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
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. write
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
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
On Thu, Oct 10, 2013 at 7:59 AM, Andreas Gal andreas@gmail.com 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
On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit
t...@tillschneidereit.net wrote:
On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto gsve...@mozilla.com 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
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.
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
On Thu, Oct 10, 2013 at 6:56 PM, Brian Smith br...@briansmith.org 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
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
___
On Thursday, October 10, 2013 6:58:24 PM UTC+2, Boris Zbarsky wrote:
That's ... quite odd. Scripts loaded via a script tag get the
principal of the page that loaded them. Is this how you're loading your
scripts?
Yes. Not sure if it's relevant but the remote script (and some of the local
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 script tag is added
dynamically to the document after if has finished loading.
Shouldn't matter.
So you're
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
2013/10/10 Benoit Jacob jacob.benoi...@gmail.com
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
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
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
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
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
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
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.
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
On Thu, Oct 10, 2013 at 9:42 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
On Oct 10, 2013 7:26 PM, Adam Roach a...@mozilla.com wrote:
[java source] --javac- [java bytecode] --llvm- [llvm bitcode]
--emscripten- [javascript]
Or easier: [java source] --GWT- [javascript]
___
dev-platform mailing list
On 2013-10-10 4:47 PM, Henri Sivonen wrote:
On Oct 10, 2013 7:26 PM, Adam Roach a...@mozilla.com wrote:
[java source] --javac- [java bytecode] --llvm- [llvm bitcode]
--emscripten- [javascript]
Or easier: [java source] --GWT- [javascript]
Adam asked specifically about the Emscripten case,
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 in...@mozilla.com
To: every...@mozilla.org
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
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
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 commitment,
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
On 2013-10-10 12:56 PM, Brian Smith wrote:
On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit
t...@tillschneidereit.net wrote:
On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto gsve...@mozilla.com wrote:
On 10/10/2013 02:36, Zack Weinberg wrote:
In that vein, I think we should take a hard
53 matches
Mail list logo
