Re: Audit your code if you use mozilla::WeakPtr

2013-10-09 Thread Boris Zbarsky

On 10/8/13 10:32 PM, Justin Dolske wrote:

Would that be a kungFuDeathGrep? (Sorry. Just making weak pun.)


You mean mozilla::WeakpPunT?

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


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

2013-10-09 Thread Mook

On 10/02/2013 12:33 PM, Erik Rose wrote:

What features do you most use in MXR and DXR?
(Apologies for the late reply; didn't really check newsgroups during the 
summit - bad wifi and having too much to do.  Didn't about the design 
session in SC for the same reason.)


I look up XPCOM interfaces a lot; as an example, 
http://dxr.mozilla.org/mozilla-central/search?q=nsIObserverService 
doesn't seem very useful - the actual interface definition is near the 
bottom.  The various type/function/whatever forms in the advanced search 
just returns nothing.  (Other than the path search, of course, but not 
all interfaces are files named after them.)  The equivalent webidl 
search would be something like 
http://dxr.mozilla.org/mozilla-central/search?q=HTMLBaseElement 
(type:HTMLBaseElement finds no results).


++ on unifying identifier search (across types of identifiers), tree 
switching, blame integration, rev pinning, etc - things already covered 
by the wiki.  (In roughly that order.)


HTH,

--
Mook
(now with a face XD )
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: C++ Standards Committee meeting next week

2013-10-09 Thread Jeff Walden
On 10/02/2013 06:06 PM, Botond Ballo wrote:
 Having to repeat 'expr' is rather unfortunate, and C++14
 fixes that. You can now write:
 
   auto function(A a, B b)
   {
   return expr;
   }
 
 The only restriction is 
 that if there are multiple return expressions, they
 must all have the same type.

Same type as in the std::is_same sense?  Or same type in the a?b:c sense, where 
b/c can be different types, and one expression must convert to the other's 
type?  I assume you mean the former, but I can imagine cases (think pointers 
and nullptr) where the latter would definitely be nice.

Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


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

2013-10-09 Thread Nicholas Nethercote
On Wed, Oct 9, 2013 at 1:49 AM, Neil n...@parkwaycc.co.uk wrote:

 Nor can I seem to get regexp search to work; I never get any results.

If you're using the regexp field in the advanced search, you're
probably failing to put '/' (or some other delimiter) at the start and
end.  I too was having trouble with this until very recently.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


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

2013-10-09 Thread Neil

Nicholas Nethercote wrote:


On Wed, Oct 9, 2013 at 1:49 AM, Neil n...@parkwaycc.co.uk wrote:
 


Nor can I seem to get regexp search to work; I never get any results.
   


If you're using the regexp field in the advanced search, you're probably 
failing to put '/' (or some other delimiter) at the start and end.  I too was 
having trouble with this until very recently.
 


Thanks, that made regexp: search work for me.

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Supporting the Windows Certificate Store

2013-10-09 Thread n24289
On Wednesday, January 9, 2013 12:17:12 PM UTC-5, joshu...@gmail.com wrote:
 I know that there are probably well thought out reasons that this isn't a
 features already...BUT! Lot's of US Government users can't use Firefox 
 because it doesn't use the Windows certificate store. 

Months late to this party, but I do not believe there is a well-thought-out 
reason why Firefox does not support the MS certificate store. There are 
rationalizations, certainly, and those who make them probably feel they are 
justified--but the bottom line is that Chrome, Safari, and IE all support MS' 
native certificate store, and so should Firefox. 

In this case, yes: if all the other lemmings are jumping off the cliff, so 
should Firefox. Make it opt-in if necessary, but make it happen.  That way end 
users won't have to dick around with multiple certificate stores in order to 
use Firefox, and the developers can feel they're maintaining their principled, 
if esoteric, stand.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


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

2013-10-09 Thread Andrew Halberstadt


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


On 10/02/2013 03:33 PM, Erik Rose wrote:

What features do you most use in MXR and DXR?

Over in the recently renamed Web Engineering group, we're working hard to 
retire MXR. It hasn't been maintained for a long time, and there's a lot of 
duplication between it and DXR, which rests upon a more modern foundation and 
has been developing like crazy. However, there are some holes we need to fill 
before we can expect you to make a Big Switch. An obvious one is indexing more 
trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs 
to squash. But I'd like to hear from you, the actual users, so it's not just me 
and Taras guessing at priorities.

What keeps you off DXR? (What are the MXR things you use constantly? Or the 
things which are seldom-used but vital?)

If you're already using DXR as part of your workflow, what could it do to make 
your work more fun?

Feel free to reply here, or attach a comment to this blog post, which talks 
about some of the things we've done recently and are considering for the future:

https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/

We'll use your input to build our priorities for Q4, so wish away!

Cheers,
Erik


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


What platform features can we kill?

2013-10-09 Thread Gervase Markham
Attack surface reduction works:
http://blog.gerv.net/2013/10/attack-surface-reduction-works/

Removing E4X broke the NSA's EGOTISTICALGOAT attack - a type confusion
vulnerability in E4X.

In the spirit of learning from this, what's next on the chopping block?

A quick survey of the security-group led to the following suggestions,
and I'm sure there are more:

* JS engine: Proxy.create, Object.prototype.watch, __noSuchMethod__,
legacy (pre-ES6) generators, __iterator__, non-ES6 let-blocks, pre-ES6
expression closures

* Editor (share a JS implementation with Servo instead)

* Most OOM recovery in the JS engine

* FTP (perhaps replace with JS implementation from FireFTP)

* Windows integrated auth

* 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
)

Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Boris Zbarsky

On 10/9/13 12:01 PM, Gervase Markham wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF


* XSLT (Chrome have already announced they will remove it:


We'd need to do the same extension thing they're proposing or something; 
this is used in the wild for sites that people care about.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Benjamin Smedberg

On 10/9/2013 12:18 PM, Boris Zbarsky wrote:

On 10/9/13 12:01 PM, Gervase Markham wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF
I'm all for this, although the risk is probably quite small because we 
don't expose RDF to content.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Extensibility of JavaScript modules

2013-10-09 Thread Jason Orendorff

On 10/8/13 4:27 PM, David Rajchenbach-Teller wrote:

That sounds quite sufficient for me.
Do we have plans to backport Cu.import to ES6 modules?


No plans yet. Want to work on it with us? We're not ready to start just 
now, but parser support for ES6 modules is being added, and the 
self-hosted implementation of Loader is underway at 
https://github.com/jorendorff/js-loaders.


-j

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Brian Smith
On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham g...@mozilla.org wrote:
 * Windows integrated auth

I would love to kill Windows integrated auth. It seems like doing so
would mean almost the same thing as saying we don't care about
intranets though. That's something I would be very interested in
hearing about from the Product team.

We should remove the legacy window.crypto.* (MOZ_DOMCRYPTO_LEGACY)
stuff described at [1]. (Warning: The features mentioned in this
article are proprietary Mozilla extensions, and are not supported in
any other browser.) I am working on sorting out the politics of doing
so on dev-tech-crypto [2].

[1] https://developer.mozilla.org/en-US/docs/JavaScript_crypto
[2] 
https://groups.google.com/d/msg/mozilla.dev.tech.crypto/FRmpYubnan4/DDiAtniVW-0J

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread gNeandr

On 09.10.2013 18:01, 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


 CON to remove XSLT support from platform!
XML/XSLT is used for printing ICS calendar data to get web page output 
in form of agenda/dairy lists. This is the most flexible form a user can 
get for his/her requirements. All can be configured by the user outside 
of the extension code!

Removing XSLT would remove this flexibility. Not good  ;(


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Chris Peterson

On 10/9/13 9:49 AM, Benjamin Smedberg wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF

I'm all for this, although the risk is probably quite small because we
don't expose RDF to content.


Bug 833098 - Kick RDF out of Firefox

Comments in the bug suggest a build-time flag because Thunderbird needs 
on RDF.



chris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Jonathan Kew

On 9/10/13 17:18, Boris Zbarsky wrote:

On 10/9/13 12:01 PM, Gervase Markham wrote:

In the spirit of learning from this, what's next on the chopping block?



* XSLT (Chrome have already announced they will remove it:


Have they? I admit I haven't made it through every post in their 
discussion threads, but AFAICS, some people from Chrome have expressed 
an interest in removing it, but this suggestion generated considerable 
debate (including some definite opposition to the idea).




We'd need to do the same extension thing they're proposing or something;
this is used in the wild for sites that people care about.


It's used in the wild on the web, and I've also known it to be used 
locally as a convenient tool to present views of data files that happen 
to be maintained in XML format.


Moving it to an extension (so that it isn't available unless the user is 
aware of it and explicitly installs support) would seem like a negative 
step, though if usage is rare/specialized enough, perhaps it would be 
OK. But I think we should be very hesitant to entirely remove XSLT 
support from the platform.


JK

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Ehsan Akhgari

On 2013-10-09 12:18 PM, Boris Zbarsky wrote:

On 10/9/13 12:01 PM, Gervase Markham wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF


We use RDF in Firefox, in localstore.rdf among others I guess.


* XSLT (Chrome have already announced they will remove it:


We'd need to do the same extension thing they're proposing or something;
this is used in the wild for sites that people care about.


We use XSLT in our products in a few places I guess, including 
http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/extensions.xml#l1373 
:(


Also, note that I don't think the Blink folks have reached a consensus 
on whether they can remove XSLT or not yet.


Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Ehsan Akhgari

On 2013-10-09 12:01 PM, Gervase Markham wrote:

* Editor (share a JS implementation with Servo instead)


I've been fantacizing about this for a while (not about the Servo code 
sharing part per se of course.)  This is hard because of a variety of 
reasons, including the fact that there is no real spec for editing.  But 
I've also heard recent rumors that the Blink people want their editing 
code out of their core code as well...  So it would be interesting to 
keep watching this space.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Boris Zbarsky

On 10/9/13 2:25 PM, Ehsan Akhgari wrote:

On 2013-10-09 12:18 PM, Boris Zbarsky wrote:

On 10/9/13 12:01 PM, Gervase Markham wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF


We use RDF in Firefox, in localstore.rdf among others I guess.


Right.  We should stop doing that.  ;)

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Neil

Gervase Markham wrote:


* XSLT


Doesn't the XML prettyprinter use XSLT?

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Neil

Gervase Markham wrote:


* Editor (share a JS implementation with Servo instead)

By the time the editor works in Servo, you probably want to think about 
reducing your attack surface by switching to Servo instead.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Justin Dolske

On 10/9/13 11:29 AM, Boris Zbarsky wrote:


RDF


We use RDF in Firefox, in localstore.rdf among others I guess.


Right.  We should stop doing that.  ;)


Bug 559505 - localstore.rdf kills ponies

I got hung up on the (ancient) patch there because RDF is baked pretty 
firmly into the XUL Tree API.


(Hey, I just thought of another thing to add to the chopping block.)

Justin

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Shumway UX

2013-10-09 Thread Jet Villegas
Hi All:

I hope everyone had a chance to see Shumway on the big screen at the Summit. 
I'm very proud of what the Shumway team has accomplished to date. While the 
demos looked amazing, we've got quite a bit to do to get Shumway to a 
product-ready state. In particular, the user experience on desktop and mobile 
need focused design and integration work to get right. The integration with 
other Firefox features (eg. click-to-play) also needs special consideration. 

I'm preparing some mock-ups of some ideas I have re: UX based on my own 
observations and experiences with both Shumway and the Adobe Flash Player. I 
should have these ready to share by the end of the week. I'm not alone in 
thinking about the problems to solve here, and I'd like to get the discussion 
going on this thread. Please share your own experiences/concerns/ideas. 

We meet every Thursday at 11:00AM Pacific. Please join us on the #shumway IRC 
channel to get the meeting details.

Thanks,

--Jet

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Benjamin Smedberg

On 10/9/2013 2:25 PM, Ehsan Akhgari wrote:

On 2013-10-09 12:18 PM, Boris Zbarsky wrote:

On 10/9/13 12:01 PM, Gervase Markham wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF


We use RDF in Firefox, in localstore.rdf among others I guess.
This is not that hard to fix. AFAIK there's nothing that intrinsically 
ties XUL persistence to localstore.rdf, and we already have an import 
library for RDF written in JS. So it's mainly a question of hooking XUL 
persistence up to something simpler (probably storage).


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Shumway UX

2013-10-09 Thread Erin Lancaster
During the Thursday, October 17th meeting, we will have guest stars Mary 
Trombley and IIana Segall from User Research joining us to share their findings 
from the Flash CTP research project they conducted earlier this year. 

(I'll send out a reminder next week).

Erin 
On Oct 9, 2013, at 12:05 PM, Jet Villegas j...@mozilla.com wrote:

 Hi All:
 
 I hope everyone had a chance to see Shumway on the big screen at the Summit. 
 I'm very proud of what the Shumway team has accomplished to date. While the 
 demos looked amazing, we've got quite a bit to do to get Shumway to a 
 product-ready state. In particular, the user experience on desktop and mobile 
 need focused design and integration work to get right. The integration with 
 other Firefox features (eg. click-to-play) also needs special consideration. 
 
 I'm preparing some mock-ups of some ideas I have re: UX based on my own 
 observations and experiences with both Shumway and the Adobe Flash Player. I 
 should have these ready to share by the end of the week. I'm not alone in 
 thinking about the problems to solve here, and I'd like to get the discussion 
 going on this thread. Please share your own experiences/concerns/ideas. 
 
 We meet every Thursday at 11:00AM Pacific. Please join us on the #shumway IRC 
 channel to get the meeting details.
 
 Thanks,
 
 --Jet
 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Brian Smith
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 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), there's hardly any
resources to do anything to actually fix any of these problems other
than remove it, and it slows down progress on important security
features.

Cheers,
Brian
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Axel Hecht

On 10/9/13 6:18 PM, Boris Zbarsky wrote:

On 10/9/13 12:01 PM, Gervase Markham wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF


Yes.

I think that localstore.rdf is the long pole. Not so much because we 
abuse it for xul persistance, that's OK to fix. The thing that bothers 
me most is all of those addons that probably still use it.


I'd love if we could get some data about that in particular, and RDF 
usage in addons in general.


And then there's mailnews, of course. That one's sad. Close, but we 
moved everyone off of mailnews just before it got rid of RDF, IIRC.


Axel

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Migrating to Win64 rev2 machines

2013-10-09 Thread John Hopkins
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 deploy new instances, make image
changes, etc.

It uses the same build toolchain as the current Windows 64-bit images
(MSVC10) but located at different paths so you'll notice conditional
checks like
http://hg.mozilla.org/mozilla-central/file/a141e39bf6da/build/win64/mozconfig.vs2010#l2
which will be uplifted.

The 'cedar' project branch has been building successfully using the new
image. The plan is to migrate other branches over the next few weeks in
this order:
- remaining project branches
- mozilla-central
- mozilla-inbound, b2g-inbound
- try
- aurora
- beta
- release, mozilla-b2g18*
- esr

Wait times may increase for a short time on days that we cut over to the
new build machines (since we are reimaging existing machines in chunks).
 We'll be keeping an eye on those wait times and adjusting the number of
machines cut over if needed.  Thunderbird comm-* branches will be cut
over at the same time as their mozilla-* counterpart.

The project branches will be cut over tomorrow and we'll let those build
over the weekend before cutting over mozilla-central. I will send an
email notification on this thread before and after a cutover so everyone
knows the current status.

Bug 781277 tracks this effort.  If you have any questions or concerns,
please let me know.

Thanks,
John
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Ehsan Akhgari

On 2013-10-09 2:39 PM, Neil wrote:

Gervase Markham wrote:


* XSLT


Doesn't the XML prettyprinter use XSLT?


It does: 
http://mxr.mozilla.org/mozilla-central/source/content/xml/document/resources/XMLPrettyPrint.xsl?force=1


We also use it for about:memory apparently.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Botond Ballo
 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), there's hardly any
 resources to do anything to actually fix any of these problems other
 than remove it, and it slows down progress on important security
 features.

I use master password. Is there something I can use instead that's
more secure?

Thanks,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Migrating to Win64 rev2 machines

2013-10-09 Thread Ben Hearsum
Hey Jet,

I'd say that this greenery project is completely aside from the work
John is doing -- build and tests machines are generally separate.

Are you looking for you (or someone else) to have access to a machine to
green up tests on your own, or looking to have tests run as part of the
normal automation (or maybe on Try?)?

- Ben

On 10/09/13 05:35 PM, Jet Villegas wrote:
 I'm currently looking for someone to green up the tests on Win64. Can we 
 dedicate one machine instance (I'm assuming this is on AWS?) for the purpose 
 of advancing this greenery project? Also, who is the point-person on Release 
 Engineering that we should pull into the testing discussion?
 
 Thanks,
 
 --Jet
 
 - Original Message -
 From: John Hopkins jhopk...@mozilla.com
 To: dev.platform dev-platform@lists.mozilla.org
 Cc: sheri...@mozilla.com
 Sent: Wednesday, October 9, 2013 2:22:52 PM
 Subject: Migrating to Win64 rev2 machines
 
 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 deploy new instances, make image
 changes, etc.
 
 It uses the same build toolchain as the current Windows 64-bit images
 (MSVC10) but located at different paths so you'll notice conditional
 checks like
 http://hg.mozilla.org/mozilla-central/file/a141e39bf6da/build/win64/mozconfig.vs2010#l2
 which will be uplifted.
 
 The 'cedar' project branch has been building successfully using the new
 image. The plan is to migrate other branches over the next few weeks in
 this order:
 - remaining project branches
 - mozilla-central
 - mozilla-inbound, b2g-inbound
 - try
 - aurora
 - beta
 - release, mozilla-b2g18*
 - esr
 
 Wait times may increase for a short time on days that we cut over to the
 new build machines (since we are reimaging existing machines in chunks).
  We'll be keeping an eye on those wait times and adjusting the number of
 machines cut over if needed.  Thunderbird comm-* branches will be cut
 over at the same time as their mozilla-* counterpart.
 
 The project branches will be cut over tomorrow and we'll let those build
 over the weekend before cutting over mozilla-central. I will send an
 email notification on this thread before and after a cutover so everyone
 knows the current status.
 
 Bug 781277 tracks this effort.  If you have any questions or concerns,
 please let me know.
 
 Thanks,
 John
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Extensibility of JavaScript modules

2013-10-09 Thread Jason Orendorff

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 Loader hooks to make the `import` keyword behave like Cu.import

2. somehow have those hooks installed by default in every chrome window

And maybe:

3. migrate existing Cu.import call sites to ES6 `import`

4. reimplement Cu.import and friends on top of the Loader API

But I'm not sure 3 and 4 are possible. ES6 modules are designed for the 
web and so are inherently asynchronous. Cu.import is synchronous. 
Switching poses some risks.


-j

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


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

2013-10-09 Thread Erik Rose
Thanks, everyone, for your thoughtful and voluminous input! I bequeath you the 
following behind-the-scenes links so you can see the effect your feedback is 
having on DXR's future.

We've collected, de-duped, and categorized your feedback at 
https://wiki.mozilla.org/DXR_UI_Refresh#Feedback. If you see your request 
grossly mischaracterized or omitted, feel free to edit. I'm watching the page.

I've done a first cut at immediate goals just above that, at 
https://wiki.mozilla.org/DXR_UI_Refresh#Plans_And_Priorities.

Finally, there's a rough draft at a revised (and more sensical) query syntax up 
at https://github.com/erikrose/dxr/blob/query-parser/docs/queries.rst.

This is just the beginning. I'll be posting updates at 
https://blog.mozilla.org/webdev/tag/dxr/ whenever there's something useful to 
say, and you can watch the DXR_UI_Refresh wiki page if you want more frequent 
updates.

Cheers,
Erik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Migrating to Win64 rev2 machines

2013-10-09 Thread Jet Villegas
I think we could have it happen in this order:

1. a way to green up tests on a single machine hooked up to a build server
2. put this on Try
3. put this on production automation

Of course, it would be awesome if we could skip #1 and go to #2 directly as we 
green up the tests, as this will open it up to multiple contributors for the 
test greening.

--Jet 

- Original Message -
From: Ben Hearsum bhear...@mozilla.com
To: dev-platform@lists.mozilla.org
Sent: Wednesday, October 9, 2013 2:50:52 PM
Subject: Re: Migrating to Win64 rev2 machines

Hey Jet,

I'd say that this greenery project is completely aside from the work
John is doing -- build and tests machines are generally separate.

Are you looking for you (or someone else) to have access to a machine to
green up tests on your own, or looking to have tests run as part of the
normal automation (or maybe on Try?)?

- Ben

On 10/09/13 05:35 PM, Jet Villegas wrote:
 I'm currently looking for someone to green up the tests on Win64. Can we 
 dedicate one machine instance (I'm assuming this is on AWS?) for the purpose 
 of advancing this greenery project? Also, who is the point-person on Release 
 Engineering that we should pull into the testing discussion?
 
 Thanks,
 
 --Jet
 
 - Original Message -
 From: John Hopkins jhopk...@mozilla.com
 To: dev.platform dev-platform@lists.mozilla.org
 Cc: sheri...@mozilla.com
 Sent: Wednesday, October 9, 2013 2:22:52 PM
 Subject: Migrating to Win64 rev2 machines
 
 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 deploy new instances, make image
 changes, etc.
 
 It uses the same build toolchain as the current Windows 64-bit images
 (MSVC10) but located at different paths so you'll notice conditional
 checks like
 http://hg.mozilla.org/mozilla-central/file/a141e39bf6da/build/win64/mozconfig.vs2010#l2
 which will be uplifted.
 
 The 'cedar' project branch has been building successfully using the new
 image. The plan is to migrate other branches over the next few weeks in
 this order:
 - remaining project branches
 - mozilla-central
 - mozilla-inbound, b2g-inbound
 - try
 - aurora
 - beta
 - release, mozilla-b2g18*
 - esr
 
 Wait times may increase for a short time on days that we cut over to the
 new build machines (since we are reimaging existing machines in chunks).
  We'll be keeping an eye on those wait times and adjusting the number of
 machines cut over if needed.  Thunderbird comm-* branches will be cut
 over at the same time as their mozilla-* counterpart.
 
 The project branches will be cut over tomorrow and we'll let those build
 over the weekend before cutting over mozilla-central. I will send an
 email notification on this thread before and after a cutover so everyone
 knows the current status.
 
 Bug 781277 tracks this effort.  If you have any questions or concerns,
 please let me know.
 
 Thanks,
 John
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Migrating to Win64 rev2 machines

2013-10-09 Thread Ben Hearsum
On 10/09/13 06:29 PM, Jet Villegas wrote:
 I think we could have it happen in this order:
 
 1. a way to green up tests on a single machine hooked up to a build server
 2. put this on Try
 3. put this on production automation
 
 Of course, it would be awesome if we could skip #1 and go to #2 directly as 
 we green up the tests, as this will open it up to multiple contributors for 
 the test greening.

Single dedicated machines aren't really a thing for us, so #1 isn't
actually doable.

While research what it would take to do #2 I noticed that we already
have 64-bit Windows tests running over on the Date branch! I'm not fully
in the loop on this, but I believe this was revived within the last
couple of months. Results are over here: https://tbpl.mozilla.org/?tree=Date

We could probably make it possible to run them on Try, but I should
defer to Chris AtLee or John Hopkins at this point, as they've got much
more context on this than me.

- Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Migrating to Win64 rev2 machines

2013-10-09 Thread Ben Hearsum
On 10/09/13 06:49 PM, Ben Hearsum wrote:
 We could probably make it possible to run them on Try, but I should
 defer to Chris AtLee or John Hopkins at this point, as they've got much
 more context on this than me.

OK, one more reply from: These _are_ enabled on Try, but the try syntax
to use them is undocumented. Pushing with try: -b o -p win64 -u
all[win64_vm] -t none should get you a full suite of tests. You can
also use the normal subselection by replacing all with reftest or
similar.

- Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Philipp Kewisch

On 10/9/13 6:01 PM, Gervase Markham wrote:

Attack surface reduction works:
http://blog.gerv.net/2013/10/attack-surface-reduction-works/

Removing E4X broke the NSA's EGOTISTICALGOAT attack - a type confusion
vulnerability in E4X.

In the spirit of learning from this, what's next on the chopping block?


So you are saying, we should start removing features that could decrease 
the attack surface? So then lets remove JavaScript, this could 
definitely decrease the attack surface.


I think its the wrong conclusion, shouldn't we rather be fixing security 
holes and analysing the code for vulnerabilities than removing random 
things just because of their potential risk?


Removing features will definitely make people unhappy, and more work for 
(extension) authors needing to adapt to the platform changes yet again.


Philipp

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Migrating to Win64 rev2 machines

2013-10-09 Thread Jet Villegas
Excellent. 

Now to find willing volunteer(s.) Windows 64 represents a key platform for us 
now that we've opened up Firefox for high-performance graphics via WebGL and 
Canvas. Freeing up the CPU by going to the GPU exposes the next bottleneck: 
Memory Bandwidth. 

Can you help get the test failures fixed? Please reply to me if you can 
contribute here.

Thanks,

--Jet

- Original Message -
From: Ben Hearsum bhear...@mozilla.com
To: dev-platform@lists.mozilla.org
Sent: Wednesday, October 9, 2013 4:15:04 PM
Subject: Re: Migrating to Win64 rev2 machines

On 10/09/13 06:49 PM, Ben Hearsum wrote:
 We could probably make it possible to run them on Try, but I should
 defer to Chris AtLee or John Hopkins at this point, as they've got much
 more context on this than me.

OK, one more reply from: These _are_ enabled on Try, but the try syntax
to use them is undocumented. Pushing with try: -b o -p win64 -u
all[win64_vm] -t none should get you a full suite of tests. You can
also use the normal subselection by replacing all with reftest or
similar.

- Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Jim Porter

On 10/09/2013 12:37 PM, Chris Peterson wrote:

On 10/9/13 9:49 AM, Benjamin Smedberg wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF

I'm all for this, although the risk is probably quite small because we
don't expose RDF to content.


Bug 833098 - Kick RDF out of Firefox

Comments in the bug suggest a build-time flag because Thunderbird needs
on RDF.


Thunderbird doesn't really want RDF either. However, killing RDF in 
Thunderbird has been a slow process. If there's anyone who wants to help 
kill RDF in Thunderbird, go for it!


- Jim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Migrating to Win64 rev2 machines

2013-10-09 Thread Kyle Huey
Did we start caring about Win64 again recently?

+bsmedberg

- Kyle


On Wed, Oct 9, 2013 at 7:33 PM, Jet Villegas j...@mozilla.com wrote:

 Excellent.

 Now to find willing volunteer(s.) Windows 64 represents a key platform for
 us now that we've opened up Firefox for high-performance graphics via WebGL
 and Canvas. Freeing up the CPU by going to the GPU exposes the next
 bottleneck: Memory Bandwidth.

 Can you help get the test failures fixed? Please reply to me if you can
 contribute here.

 Thanks,

 --Jet

 - Original Message -
 From: Ben Hearsum bhear...@mozilla.com
 To: dev-platform@lists.mozilla.org
 Sent: Wednesday, October 9, 2013 4:15:04 PM
 Subject: Re: Migrating to Win64 rev2 machines

 On 10/09/13 06:49 PM, Ben Hearsum wrote:
  We could probably make it possible to run them on Try, but I should
  defer to Chris AtLee or John Hopkins at this point, as they've got much
  more context on this than me.

 OK, one more reply from: These _are_ enabled on Try, but the try syntax
 to use them is undocumented. Pushing with try: -b o -p win64 -u
 all[win64_vm] -t none should get you a full suite of tests. You can
 also use the normal subselection by replacing all with reftest or
 similar.

 - Ben
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Joshua Cranmer 

On 10/9/2013 11:18 AM, Boris Zbarsky wrote:

On 10/9/13 12:01 PM, Gervase Markham wrote:

In the spirit of learning from this, what's next on the chopping block?


RDF


Having gone through some of the ancient security bugs, it looks like the 
walking-security-hole aspect of RDF was limited mostly to mailnew's 
horrific abuse of it for folders. That aspect I have a plan to 
eliminate; the use of it for templated UI is, too my knowledge, not a 
security issue per se.


Also, to those who believe that localstore.rdf is the only use of RDF 
remaining in Firefox, I can only cock my head and laugh. MXR reveals 
that charsets, mimetypes, and help (which is in toolkit, but may only be 
in SeaMonkey these days) are still present uses in mozilla-central. And 
I'm sure that a significant number of addons still use it. (I'd refer 
you to an MXR results for addons, but this is the sort of thing where it 
fails miserably since it doesn't let me search only addons that work on 
maintained versions of Firefox).


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Zack Weinberg

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 
things like XSLT where there's no question but what it increases our 
attack surface, but there is also a strong (if small) constituency. 
Where it is currently impossible to do something in JS, that points at a 
weakness in the platform - whether capabilities or just speed.


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 an improvement to justify the 
additional glob of compiled code. Web-deliverable JS image decoders 
could open that up.


The other thing that comes to mind is, if Web Components lives up to its 
promise, perhaps it could be used for the built-in form controls? 
That's also a big pile of hair, and form elements in odd places have 
been an ongoing source of crasher bugs.


zw
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Gavin Sharp
On Wed, Oct 9, 2013 at 4:28 PM, Philipp Kewisch mozi...@kewis.ch wrote:
 I think its the wrong conclusion, shouldn't we rather be fixing security
 holes and analysing the code for vulnerabilities than removing random things
 just because of their potential risk?

Those options are not mutually exclusive; we should be doing both.

There's obvious value in thinking about ways to reduce our attack
surface, and that's all Gerv was suggesting we do. Obviously there are
tradeoffs involved, and we need to evaluate them when making any
decisions. Arguing that removing anything would be equivalent to
removing support for JS is not really useful.

I don't think anyone in this thread was actually mistaken into
thinking that removing RDF or XSLT was as simple as an hg rm. That
removing them is harder than that doesn't mean it's not worth thinking
about (and indeed much thinking about it has been done, in e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=833098).

Gavin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Boris Zbarsky

On 10/9/13 8:36 PM, Zack Weinberg wrote:

if Web Components lives up to its
promise, perhaps it could be used for the built-in form controls?


For what it's worth, we've tried that with XBL.  It died on the 
performance and memory usage beach...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Migrating to Win64 rev2 machines

2013-10-09 Thread John Hopkins
Hi, Jet:

On 13-10-09 5:35 PM, Jet Villegas wrote:
 I'm currently looking for someone to green up the tests on Win64. Can we 
 dedicate one machine instance (I'm assuming this is on AWS?) for the purpose 
 of advancing this greenery project? Also, who is the point-person on Release 
 Engineering that we should pull into the testing discussion?

This switchover is specifically for the build machines, not test
machines.  You probably want bug 886640.

Thanks,
John

 - Original Message -
 From: John Hopkins jhopk...@mozilla.com
 To: dev.platform dev-platform@lists.mozilla.org
 Cc: sheri...@mozilla.com
 Sent: Wednesday, October 9, 2013 2:22:52 PM
 Subject: Migrating to Win64 rev2 machines
 
 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 deploy new instances, make image
 changes, etc.
 
 It uses the same build toolchain as the current Windows 64-bit images
 (MSVC10) but located at different paths so you'll notice conditional
 checks like
 http://hg.mozilla.org/mozilla-central/file/a141e39bf6da/build/win64/mozconfig.vs2010#l2
 which will be uplifted.
 
 The 'cedar' project branch has been building successfully using the new
 image. The plan is to migrate other branches over the next few weeks in
 this order:
 - remaining project branches
 - mozilla-central
 - mozilla-inbound, b2g-inbound
 - try
 - aurora
 - beta
 - release, mozilla-b2g18*
 - esr
 
 Wait times may increase for a short time on days that we cut over to the
 new build machines (since we are reimaging existing machines in chunks).
  We'll be keeping an eye on those wait times and adjusting the number of
 machines cut over if needed.  Thunderbird comm-* branches will be cut
 over at the same time as their mozilla-* counterpart.
 
 The project branches will be cut over tomorrow and we'll let those build
 over the weekend before cutting over mozilla-central. I will send an
 email notification on this thread before and after a cutover so everyone
 knows the current status.
 
 Bug 781277 tracks this effort.  If you have any questions or concerns,
 please let me know.
 
 Thanks,
 John
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Nicholas Nethercote
On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgari ehsan.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.

 * Most OOM recovery in the JS engine

In the past that has been left alone due to the preference of the JS
engine module owner. Perhaps the new JS engine module owners can say
what they think about it.

 * XSLT

 We also use it for about:memory apparently.

We do?  Can you show me where?

 In that vein, I think we should take a hard look at the image decoders.

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 credible language in non-experimental
systems.  Image decoders were the first component that came up as a
possibility.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What platform features can we kill?

2013-10-09 Thread Mike Hommey
On Wed, Oct 09, 2013 at 08:18:16PM -0700, Nicholas Nethercote 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 credible language in non-experimental
 systems.  Image decoders were the first component that came up as a
 possibility.

The problem with that plan is that bootstrapping the rust compiler is kind
of a problem at the moment, both for trusting trust, and for shipping in
e.g. linux distros.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform