Re: Valgrind-on-TBPL

2013-12-12 Thread Nicholas Nethercote
On Thu, Dec 12, 2013 at 9:48 AM, Nicholas Nethercote wrote: >> >> Unfortunately, on December 5th, just before the changes were enabled, >> something >> else happened that caused the Valgrind jobs to start timing out all the time. >> This is being tracked in https://bugzilla.mozilla.org/show_bug.c

Improvements to the Sphinx in-tree documentation generation

2013-12-12 Thread Gregory Szorc
After I announced the in-tree build docs powered by Sphinx a few months ago [1], a few people came to me and said "that's really cool - I want something like that for my module." I'm pleased to announce that as of bug 939367 landing in inbound a few hours ago, you can now deposit Sphinx docs a

Re: Valgrind-on-TBPL

2013-12-12 Thread Ted Mielczarek
On 12/12/2013 3:43 AM, Nicholas Nethercote wrote: > > I tracked this down to one of the Quitter files being a symlink with a > relative path, and that path was going awry when the file was copied > elsewhere within the chroot that the tests run in on the build > slaves(!) And by the time I worked

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-12 Thread taken . spc
Hi, I think two prefs are needed. In addition to the pref discussed in this topic, "make all media on any tabs be click-to-play" is needed to ensure the Web Accessibility. UAAG2 (User Agent Accessibility Guidelines 2.0) LCWD [1] contains two "Level A" success criteria related to this topic. -

Re: Reacting more strongly to low-memory situations in Firefox 25

2013-12-12 Thread Benjamin Smedberg
= Data and Background = See, as some anecdotal evidence: Bug 930797 is a user who just upgraded to Firefox 25 and is seeing these a lot. dmajor tracked this down to our video implementation creating many threads, each of which has an x86 stack as well as a 1MB memory reservation for the wow6

Re: Reacting more strongly to low-memory situations in Firefox 25

2013-12-12 Thread Nicholas Nethercote
On Fri, Dec 13, 2013 at 2:53 AM, Benjamin Smedberg wrote: > > Also, we now have the ability to use DMD builds on Windows DMD works on Windows debug builds, but doesn't currently work on opt builds. But https://bugzilla.mozilla.org/show_bug.cgi?id=947117 (compile-time) and https://bugzilla.mozi

Disabling Mac builds/tests for mozilla-b2g18 and mozilla-b2g18-v1.1.0hd

2013-12-12 Thread armenzg
Hello all, After disabling the Win7 tests on those b2g18 trees, I was told by the sheriffs that the MacOS X testing is redundant. Again: * these are repositories where only security fixes are being landed * this is not about b2g26 * we have testing coverage through Linux, Linux64, Android Noion +

Re: Disabling Mac builds/tests for mozilla-b2g18 and mozilla-b2g18-v1.1.0hd

2013-12-12 Thread Ryan VanderMeulen
On 12/12/2013 11:58 AM, arme...@mozilla.com wrote: Hello all, After disabling the Win7 tests on those b2g18 trees, I was told by the sheriffs that the MacOS X testing is redundant. Again: * these are repositories where only security fixes are being landed * this is not about b2g26 * we have test

Disabling Mac + Linux32-bit builds/tests for mozilla-b2g18 and mozilla-b2g18-v1.1.0hd

2013-12-12 Thread Armen Zambrano G.
+dev.b2g tl;dr - we want to disable Mac + Linux32-bit build/tests for mozilla-b2g18 and mozilla-b2g18-v1.1.0hd Hi Ryan, I would be fine of taking care of it if I hear no objections by next week. On 13-12-12 12:12 PM, Ryan VanderMeulen wrote: > On 12/12/2013 11:58 AM, arme...@mozilla.com wrote: >

Re: Can we start using C++ STL containers in Mozilla code?

2013-12-12 Thread Jeff Walden
On 12/10/2013 04:32 PM, Jeff Gilbert wrote: > In my experience, docs for 'our' containers are also miles behind what the > STL has available. This, not unfamiliarity to new developers, is the big issue. Developers have to learn new APIs all the time. STL versus something else shouldn't be that

(un)safety of NS_LITERAL_STRING("...").get()

2013-12-12 Thread David Keeler
Recently bug 539710 landed[0] to fix an unnecessary and apparently unsafe operation: const PRUnichar *comma = NS_LITERAL_STRING(",").get(); Curious, I did a quick search for other examples of NS_LITERAL_STRING combined with .get() and found that this appears to be common[1]. So, I have a few ques

Re: (un)safety of NS_LITERAL_STRING("...").get()

2013-12-12 Thread Joshua Cranmer 🐧
On 12/12/2013 6:52 PM, David Keeler wrote: Recently bug 539710 landed[0] to fix an unnecessary and apparently unsafe operation: const PRUnichar *comma = NS_LITERAL_STRING(",").get(); Curious, I did a quick search for other examples of NS_LITERAL_STRING combined with .get() and found that this a

Re: (un)safety of NS_LITERAL_STRING("...").get()

2013-12-12 Thread L. David Baron
On Thursday 2013-12-12 16:52 -0800, David Keeler wrote: > Recently bug 539710 landed[0] to fix an unnecessary and apparently > unsafe operation: > > const PRUnichar *comma = NS_LITERAL_STRING(",").get(); > > Curious, I did a quick search for other examples of NS_LITERAL_STRING > combined with .ge

Re: (un)safety of NS_LITERAL_STRING("...").get()

2013-12-12 Thread Trevor Saunders
On Thu, Dec 12, 2013 at 07:01:18PM -0600, Joshua Cranmer ? wrote: > On 12/12/2013 6:52 PM, David Keeler wrote: > >Recently bug 539710 landed[0] to fix an unnecessary and apparently > >unsafe operation: > > > >const PRUnichar *comma = NS_LITERAL_STRING(",").get(); > > > >Curious, I did a quick searc

Re: (un)safety of NS_LITERAL_STRING("...").get()

2013-12-12 Thread Chris Peterson
On 12/12/13, 5:09 PM, L. David Baron wrote: The preferred form would now be: #include "mozilla/Char16.h" const PRUnichar *comma = MOZ_UTF16(","); I think char16_t is preferred over PRUnichar for new code. chris ___ dev-platform mailing list

Re: (un)safety of NS_LITERAL_STRING("...").get()

2013-12-12 Thread Robert O'Callahan
On Fri, Dec 13, 2013 at 3:02 PM, Chris Peterson wrote: > On 12/12/13, 5:09 PM, L. David Baron wrote: > >> The preferred form would now be: >> >>#include "mozilla/Char16.h" >> >>const PRUnichar *comma = MOZ_UTF16(","); >> > > I think char16_t is preferred over PRUnichar for new code. > So

Re: (un)safety of NS_LITERAL_STRING("...").get()

2013-12-12 Thread Ehsan Akhgari
On 12/12/2013, 9:18 PM, Robert O'Callahan wrote: On Fri, Dec 13, 2013 at 3:02 PM, Chris Peterson wrote: On 12/12/13, 5:09 PM, L. David Baron wrote: The preferred form would now be: #include "mozilla/Char16.h" This #include is actually not needed. That header is available everywhere.

WebIDL Windows clobber issue hopefully resolved

2013-12-12 Thread Gregory Szorc
Just landed in inbound are patches that hopefully resolve the issue where WebIDL changes required a clobber on Windows. Please stop touching CLOBBER when modifying WebIDL files. Please be on the lookout for WebIDL build system oddities. Please be advised that developer workflow for updating W

Re: WebIDL Windows clobber issue hopefully resolved

2013-12-12 Thread Ryan VanderMeulen
On 12/12/2013 10:34 PM, Gregory Szorc wrote: Just landed in inbound are patches that hopefully resolve the issue where WebIDL changes required a clobber on Windows. Please stop touching CLOBBER when modifying WebIDL files. Please be on the lookout for WebIDL build system oddities. Please be adv

Re: WebIDL Windows clobber issue hopefully resolved

2013-12-12 Thread Boris Zbarsky
On 12/12/13 10:34 PM, Gregory Szorc wrote: Just landed in inbound are patches that hopefully resolve the issue where WebIDL changes required a clobber on Windows. Thank you again for picking this up and getting it done! -Boris ___ dev-platform maili