Re: PSA: Local static analysis builds on Linux and Mac OS X

On Wed, Oct 14, 2015 at 6:07 PM, Ehsan Akhgari wrote: > > On Linux, most other recent versions of clang should work too, such as the > one you usually get from your distro, provided that the dev package for > LLVM/Clang has been installed. Is there an easy way to determine if that package has bee

Re: Fwd: On the future of and application/x-x509-*-cert MIME handling

Hi, sorry for warming up this topic, I've just been pointed here. Am Donnerstag, 30. Juli 2015 01:35:49 UTC+2 schrieb David Keeler: > Ryan Sleevi recently announced the pre-intention to deprecate and > eventually remove support for the element and special-case > handling of the appl

Re: PSA: Local static analysis builds on Linux and Mac OS X

On 2015-10-14 9:18 PM, Mike Hommey wrote: BTW, since we're growing the set of checks the plugin does, what do we do to ensure that it doesn't add too much overhead to the compilation time? Currently nothing beyond taking care to not add slow checks. Since we're talking about the build speed he

Intent to unship: jar: URIs from content

We currently support URLs such as http://mxr.mozilla.org/mozilla-central/source/modules/libjar/test/mochitest/bug403331.zip?raw=1&ctype=application/java-archive!/test.html>. This is a Firefox specific feature that no other engine implements, and it increases our attack surface unnecessarily. A

Re: PSA: Local static analysis builds on Linux and Mac OS X

On 2015-10-15 5:30 AM, Nicholas Nethercote wrote: On Wed, Oct 14, 2015 at 6:07 PM, Ehsan Akhgari wrote: On Linux, most other recent versions of clang should work too, such as the one you usually get from your distro, provided that the dev package for LLVM/Clang has been installed. Is there a

Re: PSA: Local static analysis builds on Linux and Mac OS X

On 2015-10-14 9:32 PM, Gregory Szorc wrote: On Wed, Oct 14, 2015 at 6:07 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: Last weekend, I finished upgrading our Linux and OS X debug and opt static analysis builds ("S" jobs on TreeHerder) to the latest revision of clang 3

Re: Intent to unship: jar: URIs from content

SGTM! On 10/15/2015 11:58 AM, Ehsan Akhgari wrote: We currently support URLs such as http://mxr.mozilla.org/mozilla-central/source/modules/libjar/test/mochitest/bug403331.zip?raw=1&ctype=application/java-archive!/test.html>. This is a Firefox specific feature that no other engine implements,

Re: Intent to unship: jar: URIs from content

Huzzah! Thanks for fixing this Ehsan. On Thu, Oct 15, 2015 at 10:58 AM, Ehsan Akhgari wrote: > We currently support URLs such as http://mxr.mozilla.org/mozilla-central/source/modules/libjar/test/mochitest/bug403331.zip?raw=1&ctype=application/java-archive!/test.html>. > This is a Firefox specif

Re: Intent to unship: jar: URIs from content

On 2015-10-15 1:58 PM, Ehsan Akhgari wrote: We currently support URLs such as http://mxr.mozilla.org/mozilla-central/source/modules/libjar/test/mochitest/bug403331.zip?raw=1&ctype=application/java-archive!/test.html>. This is a Firefox specific feature that no other engine implements, and it in

Re: Intent to unship: jar: URIs from content

OMG yes please. Jason On Thu, Oct 15, 2015 at 11:31 AM, Ehsan Akhgari wrote: > On 2015-10-15 1:58 PM, Ehsan Akhgari wrote: > >> We currently support URLs such as >> > http://mxr.mozilla.org/mozilla-central/source/modules/libjar/test/mochitest/bug403331.zip?raw=1&ctype=application/java-archive!/

Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

Hey dev-platform, TL;DR: I want Gecko to stop firing events on ’s on dropdowns. Context: Bug 1090602 was filed way back in the day by someone who used the old Treestatus app, because they noticed it was broken once e10s was flipped on by default. The problem was that the old Treestatus app was

Re: PSA: Local static analysis builds on Linux and Mac OS X

On 15/10/15 01:59 PM, Ehsan Akhgari wrote: On 2015-10-14 9:18 PM, Mike Hommey wrote: BTW, since we're growing the set of checks the plugin does, what do we do to ensure that it doesn't add too much overhead to the compilation time? Currently nothing beyond taking care to not add slow checks.

Re: Intent to unship: jar: URIs from content

On Thu, Oct 15, 2015 at 10:58 AM, Ehsan Akhgari wrote: > We currently support URLs such as http://mxr.mozilla.org/mozilla-central/source/modules/libjar/test/mochitest/bug403331.zip?raw=1&ctype=application/java-archive!/test.html>. > This is a Firefox specific feature that no other engine impleme

Re: Intent to unship: jar: URIs from content

I'm sad that I won't be able to use jar: URLs to load testcases in ZIP files uploaded to Bugzilla, but this sounds like the right thing to do. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,ao

Re: Intent to unship: jar: URIs from content

Robert O'Callahan wrote: I'm sad that I won't be able to use jar: URLs to load testcases in ZIP files uploaded to Bugzilla Or indeed any ZIP-like file, once you flip the appropriate pref. -- Warning: May contain traces of nuts. ___ dev-platform mai

Re: Intent to unship: jar: URIs from content

On 2015-10-15 7:08 PM, Robert O'Callahan wrote: I'm sad that I won't be able to use jar: URLs to load testcases in ZIP files uploaded to Bugzilla, but this sounds like the right thing to do. When speaking with Boris on IRC today he also mentioned that he does use jar URLs in this way. You can

Decommissioning "dumbmake"

Hi, I started a thread with the same subject almost two years ago. The motivation hasn't changed, but the context surely has, so it's probably time to reconsider. As a reminder, "dumbmake" is the feature that makes "mach build foo/bar" sometimes rebuild in some other directories as well. For exam

Re: Decommissioning "dumbmake"

Will building in an arbitrary source directory continue to link libxul? It was really great when we stopped needing to build in toolkit/library all the time. On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey wrote: > Hi, > > I started a thread with the same subject almost two years ago. The > motivat

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote: > Will building in an arbitrary source directory continue to link libxul? It > was really great when we stopped needing to build in toolkit/library all > the time. The point is, that doesn't reliably happen currently. You should just us

Re: Decommissioning "dumbmake"

+1 For my use case breaking dumbmake is preferable given that we now have 'build binaries'. When touching commonly included header I often like to run ./mach build gfx && ./mach build binaries. This effectively let's me say 'Make sure my gfx changes are good before you recompile the rest of gecko'

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey wrote: > On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote: > > Will building in an arbitrary source directory continue to link libxul? > It > > was really great when we stopped needing to build in toolkit/library all > > the time. > > The p

Re: Decommissioning "dumbmake"

Also, interactive rebase often dirties a bunch of files unnecessarily - I know they haven't changed, but the build system doesn't. Basically, the best-effort approach of rebuilding directories saves a lot of time for certain Gecko hackers like myself, and it would be really nice if the libxul link

Re: Decommissioning "dumbmake"

On 2015-10-15 8:37 PM, Bobby Holley wrote: On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey mailto:m...@glandium.org>> wrote: On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote: > Will building in an arbitrary source directory continue to link libxul? It > was really great when

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 08:43:53PM -0400, Ehsan Akhgari wrote: > On 2015-10-15 8:37 PM, Bobby Holley wrote: > >On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey >> wrote: > > > >On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote: > >> Will building in an arbi

Re: Decommissioning "dumbmake"

On Fri, Oct 16, 2015 at 11:37 AM, Bobby Holley wrote: > > |mach build binaries| is much slower for me than the present behavior, > because I often hack on header files that are included all over the tree, > but whose #include-ers generally don't need to be rebuilt all of the time. I used to have

Intent to implement and ship ::backdrop pseudo-element for Fullscreen API

Summary: This pseudo-element is rendered immediately below every fullscreen element, and covers the other part of the document by default. This is part of the effort to update our Fullscreen API implementation to the latest spec. And it is the last non-trivial part before I'm going to unprefix the

Re: Decommissioning "dumbmake"

> |mach build binaries| is much slower for me than the present behavior, > because I often hack on header files that are included all over the tree, > but whose #include-ers generally don't need to be rebuilt all of the time. Before we had mach, I had an alias for linking libxul. If there is a sim

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 09:15:01PM -0700, Jonas Sicking wrote: > > |mach build binaries| is much slower for me than the present behavior, > > because I often hack on header files that are included all over the tree, > > but whose #include-ers generally don't need to be rebuilt all of the time. > >

Re: PSA: Local static analysis builds on Linux and Mac OS X

On Fri, Oct 16, 2015 at 5:13 AM, Ehsan Akhgari wrote: >> >> Is there an easy way to determine if that package has been installed? > > The easiest way is to turn it on in a build and see if the build succeeds. On my stock Ubuntu 15.04 box it failed... >> And if it's not installed, is there an eas