Re: Revisiting modelines in source files

On 18/06/2015 12:15, ISHIKAWA,chiaki wrote: > Unfortunately, it does not handle the particular coding style of > #if,#else,#endif in JavaScript source files since > use of C-style macro preprocessor is not quite standard. > > Nobody seems to have written a emacs mode for this C-style macro use in

Re: Revisiting modelines in source files

That reminds me: when I reformatted rr, I did manually change the code in a few places (usually around #ifdefs) so that clang-format's line breaking didn't go completely crazy. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoio

Re: Revisiting modelines in source files

Assessing style compliance as == clang-format(whole file) is by far the easiest to implement. I'd be in favor of a flag day (or set of mini flag days) where we mass rewrite the tree with clang-format's output. To be honest, I don't care WHICH particular style we follow, but please set the fl

Reminder: Tree Closing Window (TCW), Sat June 20, 0700-0900 PDT

tracker bug with details: https://bugzil.la/1175630 status at: https://whistlepig.mozilla.org/en-US/detail/368/ NOTE: the trees will be left open; devs must monitor their own builds, and retrigger as needed. IT will be performing maintenance work this Saturday, primarily in SCL3. That will ca

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 06:57:04PM -0700, Gregory Szorc wrote: > On Wed, Jun 17, 2015 at 6:29 PM, Robert O'Callahan > wrote: > > > As an experiment, we declared the coding style of rr to be "whatever > > clang-format produces with rr's .clang-format file" (which was tweaked to > > resemble Mozill

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 6:29 PM, Robert O'Callahan wrote: > As an experiment, we declared the coding style of rr to be "whatever > clang-format produces with rr's .clang-format file" (which was tweaked to > resemble Mozilla style, including an 80-char line limit). Overall I've been > very happy w

Re: Revisiting modelines in source files

As an experiment, we declared the coding style of rr to be "whatever clang-format produces with rr's .clang-format file" (which was tweaked to resemble Mozilla style, including an 80-char line limit). Overall I've been very happy with the results. Sometimes you get suboptimal linebreaking decisions

Re: Revisiting modelines in source files

On 2015-06-17 1:04 PM, Andrew McCreight wrote: As Boris said, for our particular emacs modeline there is no prompt. Actually, in some JS files I'm getting a prompt when opening them - js-indent-level isn't considered a safe variable by emacs. (although it's pretty easy to mark them as safe,

Re: The War on Warnings

On 2015/06/17 8:29, Eric Rahm wrote: An update on progress. I've landed bugs which should clean up ~180,000 warnings. I have bugs pending for another ~26,000. The latest top 40: *Note: I improved my normalization a bit so it might look a bit different Are there documents explaining why thes

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 4:57 PM, Nicholas Nethercote wrote: > (At this point I expect people to push back against my claims that the > automated tools aren't up to snuff. If you really think automated > tools can do a good enough job, please run one and submit patches > fixing up some files. I'd b

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 8:03 AM, Ehsan Akhgari wrote: > > I use vim, and the modelines are definitely useful to me. Same here. I'm also somebody who writes patches all over the codebase, and having the 2-space or 4-space indentation done automatically is *very* helpful. (I currently have a pendin

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 10:07 AM, Gregory Szorc wrote: > > Can we all agree that the needs of the many outweigh the needs of the few > and establish a consistent and enforced C++ coding style across all of > mozilla-central? There's been general consensus around this for a while now. For example,

API docs/dev/evangelism meeting tomorrow (Thursday) at 8 AM PDT

The Web API documentation community meeting, with representatives from the technical evangelism and the API development teams, will take place on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your time zone). Typical meetings include discussions about what the priorities for documen

Re: GTK3 linux builds

On Wed, Jun 17, 2015 at 01:12:01PM -0700, Julien Wajsberg wrote: > Le 17/06/2015 08:47, Jeff Muizelaar a écrit : > > As I understand it, most people on linux use distro builds. > > Not sure about this one; using the distro builds means we usually use > older versions of Firefox. I can be conside

Re: GTK3 linux builds

On Wed, Jun 17, 2015 at 11:47:26AM -0400, Jeff Muizelaar wrote: > On Wed, Jun 17, 2015 at 11:22 AM, Benjamin Smedberg > wrote: > > On 6/16/15 4:16 PM, Jeff Muizelaar wrote: > >> > >> We're working on making all of the tests green for GTK3. This means > >> that we could be changing the default linu

Re: GTK3 linux builds

I don't think there are any particularly major version-specific issues with the GTK3 builds other than the DND issue (which I've just posted a fix for). GTK 3.4 seems like a good target to me, we've been linking against features exposed in later GTK versions conditionally at runtime (i.e. hidpi)

Re: GTK3 linux builds

Le 17/06/2015 08:47, Jeff Muizelaar a écrit : > As I understand it, most people on linux use distro builds. Not sure about this one; using the distro builds means we usually use older versions of Firefox. I can be considered as an advanced user but I always used Mozilla's versions of Firefox on

Re: Revisiting modelines in source files

On 2015-06-17 1:07 PM, Gregory Szorc wrote: On Wed, Jun 17, 2015 at 8:14 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2015-06-17 11:04 AM, Mike Hoye wrote: On 2015-06-17 6:53 AM, Mike Hommey wrote: So how about removing modelines and adding editorconfig

Re: Revisiting modelines in source files

On 2015-06-17 11:18 AM, Nathan Froyd wrote: On Wed, Jun 17, 2015 at 11:03 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2015-06-17 10:49 AM, Nathan Froyd wrote: Speaking as an emacs user, I'd be OK with removing modelines, adding editorconfig files, and adding

Re: The War on Warnings

On Wednesday, June 17, 2015 at 6:49:00 AM UTC-7, kgu...@mozilla.com wrote: > > 4606 [N] WARNING: No widget found in TabParent::UpdateDimensions: file > > dom/ipc/TabParent.cpp, line 974 > > Do you know if this one occurs on b2g or also on other platforms? I added > this warning recently in

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 8:14 AM, Ehsan Akhgari wrote: > On 2015-06-17 11:04 AM, Mike Hoye wrote: > >> On 2015-06-17 6:53 AM, Mike Hommey wrote: >> >>> So how about removing modelines and adding editorconfig files? >>> >> >> I understand we're considering (or getting close to?) autoformatting >> c

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 3:53 AM, Mike Hommey wrote: > What we currently have in the tree is essentially modelines for vim and > emacs. But: > - most vim installations have modelines disabled by default because of > the security implications: https://lwn.net/Articles/20249/. > - emacs has the sa

Re: Help with building Xulrunner windows 64 bit.

W dniu 06/17/2015 o 06:33 PM, Abhay Kumar Somani pisze: > Hi, I am working in a company and we are using XULRunner to deploy our app. > Now we have decided to upgrade our app to 64bit. While upgrading we got to > know that Mozilla doesn't provides 64bitXULRunner for windows. However, while > sea

Help with building Xulrunner windows 64 bit.

Hi, I am working in a company and we are using XULRunner to deploy our app. Now we have decided to upgrade our app to 64bit. While upgrading we got to know that Mozilla doesn't provides 64bitXULRunner for windows. However, while searching in the net, I found a website that provides 64bit binarie

Re: Browser API: iframe.executeScript()

On Tue, Jun 16, 2015 at 2:48 PM, Jonas Sicking wrote: > On Tue, Jun 16, 2015 at 9:08 AM, Bobby Holley > wrote: > > Do privileged and certified apps currently have the ability to perform > > universal XSS? Because this would give them that, certainly. > > The Browser API runs content in a separat

Re: GTK3 linux builds

On Wed, Jun 17, 2015 at 11:22 AM, Benjamin Smedberg wrote: > On 6/16/15 4:16 PM, Jeff Muizelaar wrote: >> >> We're working on making all of the tests green for GTK3. This means >> that we could be changing the default linux configuration to GTK3 as >> early as FF42. > > > What are the advantages o

Re: The War on Warnings

On Wednesday, June 17, 2015 at 7:40:14 AM UTC-7, Milan Sreckovic wrote: > Do we have a all encompassing meta bug to collect all of the bugs that fix > the warnings? > -- > - Milan > Bug 765224 ___ dev-platform mailing list dev-platform@lists.mozilla.or

Re: GTK3 linux builds

On 6/16/15 4:16 PM, Jeff Muizelaar wrote: We're working on making all of the tests green for GTK3. This means that we could be changing the default linux configuration to GTK3 as early as FF42. What are the advantages of the GTK3 build? Is there a list of which distros/versions would continue

Re: Browser API: iframe.executeScript()

On 17 June 2015 at 15:57, Paul Rouget wrote: > - access the computed style of the body to update the theme of the browser > By theme do you mean like a kind of automatic theme-color? You probably know the b2g browser currently just uses the metachange event to get theme-color meta tags for this,

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 11:03 AM, Ehsan Akhgari wrote: > On 2015-06-17 10:49 AM, Nathan Froyd wrote: > >> Speaking as an emacs user, I'd be OK with removing modelines, adding >> editorconfig files, and adding .dir-locals.el files (modelines, but on a >> directory-wide basis, including subdirector

Re: Revisiting modelines in source files

On 2015-06-17 11:04 AM, Mike Hoye wrote: On 2015-06-17 6:53 AM, Mike Hommey wrote: So how about removing modelines and adding editorconfig files? I understand we're considering (or getting close to?) autoformatting code on check-in. Are we? I'm curious to know more details about that... ___

Re: Revisiting modelines in source files

On 2015-06-17 6:53 AM, Mike Hommey wrote: So how about removing modelines and adding editorconfig files? I understand we're considering (or getting close to?) autoformatting code on check-in. Intuitively* that would obsolete editor-level config, (and save some time and nit-effort) but I don

Re: Revisiting modelines in source files

On 2015-06-17 10:49 AM, Nathan Froyd wrote: On Wed, Jun 17, 2015 at 6:53 AM, Mike Hommey wrote: So how about removing modelines and adding editorconfig files? Speaking as an emacs user, I'd be OK with removing modelines, adding editorconfig

Re: Browser API: iframe.executeScript()

On Wed, Jun 17, 2015 at 4:41 PM, Benjamin Francis wrote: > On 17 June 2015 at 13:29, Paul Rouget wrote: >> >> Extending the API every time we want to do something that goes beyond the >> API >> capabilities is painful and slow. > > > Yes I'm acutely aware of this, having done it for the last thre

Re: Revisiting modelines in source files

On 6/17/15 10:01 AM, Mike Hommey wrote: modelines don't express those half-indent either. Also, they're not in the mozilla codying style, which, by the way uses 2-spaces indentations, not 4-spaces. Note that SpiderMonkey is almost entirely 4-space indent. mozilla~% grep -r "c-basic-offset: 4"

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 6:53 AM, Mike Hommey wrote: > So how about removing modelines and adding editorconfig files? > > Speaking as an emacs user, I'd be OK with removing modelines, adding editorconfig files, and adding .dir-locals.el files (mod

Re: Revisiting modelines in source files

On 6/17/15 6:53 AM, Mike Hommey wrote: - emacs has the same security implication, and AIUI, opening a file with a modeline makes emacs ask questions to the user. Or ignore them in batch mode. That depends on what's in the modeline. Pretty sure our typical "Mode: C++; tab-width: 8; inden

Re: Browser API: iframe.executeScript()

On 17 June 2015 at 13:29, Paul Rouget wrote: > Extending the API every time we want to do something that goes beyond the > API > capabilities is painful and slow. Yes I'm acutely aware of this, having done it for the last three and half years :) > The executeScript approach makes our > life a

Re: The War on Warnings

Do we have a all encompassing meta bug to collect all of the bugs that fix the warnings? — - Milan On Jun 16, 2015, at 19:29 , Eric Rahm wrote: > An update on progress. I've landed bugs which should clean up ~180,000 > warnings. I have bugs pending for another ~26,000. > > The latest top 40

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 03:13:20PM +0200, Nicolas B. Pierron wrote: > On 06/17/2015 12:53 PM, Mike Hommey wrote: > >So how about removing modelines and adding editorconfig files? > > This sounds like a good idea at first, but apparently they have no support > for half-indent, as we do have for js/

Re: The War on Warnings

> 4606 [N] WARNING: No widget found in TabParent::UpdateDimensions: file > dom/ipc/TabParent.cpp, line 974 Do you know if this one occurs on b2g or also on other platforms? I added this warning recently in bug 1125325 after smaug said [1]. It seems to be happening a lot, so we should inves

W3C Proposed Edited Recommendation: Geolocation API Specification

W3C recently published the following proposed edited recommendation (a revision of an existing W3C Recommendation to incorporate errata): Geolocation API Specification http://www.w3.org/TR/2015/PER-geolocation-API-20150528/ There's a call for review to W3C member companies (of which Mozilla i

Re: Revisiting modelines in source files

On 06/17/2015 12:53 PM, Mike Hommey wrote: So how about removing modelines and adding editorconfig files? This sounds like a good idea at first, but apparently they have no support for half-indent, as we do have for js/src/ files such as visibility keyword, and case statements. Only by read

Re: Browser API: iframe.executeScript()

On Wed, Jun 17, 2015 at 2:06 PM, Benjamin Francis wrote: > On 16 June 2015 at 16:24, Paul Rouget wrote: >> >> In bug 1174733, I'm proposing a patch to implement the equivalent of >> Google's webview.executeScript: >> >> https://developer.chrome.com/apps/tags/webview#method-executeScript >> >> Thi

Re: Browser API: iframe.executeScript()

On 16 June 2015 at 16:24, Paul Rouget wrote: > In bug 1174733, I'm proposing a patch to implement the equivalent of > Google's webview.executeScript: > > https://developer.chrome.com/apps/tags/webview#method-executeScript > > This will be useful to any consumer of the Browser API to access and >

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 07:53:18PM +0900, Mike Hommey wrote: > Hi, > > The following post visible on planet, prompted a discussion on a french > irc channel. > http://www.otsukare.info/2015/06/17/mozilla-central-sublimetext > > What we currently have in the tree is essentially modelines for vim a

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 01:02:54PM +0200, Mike de Boer wrote: > Mike, thanks for bringing this up! Huge +1 from me. > > For posterity, here’s the bug I filed almost a year ago (time flies!): > https://bugzilla.mozilla.org/show_bug.cgi?id=957564 >

Re: Revisiting modelines in source files

Mike, thanks for bringing this up! Huge +1 from me. For posterity, here’s the bug I filed almost a year ago (time flies!): https://bugzilla.mozilla.org/show_bug.cgi?id=957564 Cheers, Another Mike. > On 17 Jun 2015, at 12:53, Mike Hommey w

Revisiting modelines in source files

Hi, The following post visible on planet, prompted a discussion on a french irc channel. http://www.otsukare.info/2015/06/17/mozilla-central-sublimetext What we currently have in the tree is essentially modelines for vim and emacs. But: - most vim installations have modelines disabled by default

Re: Browser API: iframe.executeScript()

On 16.06.2015 21:41, Paul Rouget wrote: > On Tue, Jun 16, 2015 at 9:33 PM, Bobby Holley wrote: >> On Tue, Jun 16, 2015 at 12:28 PM, Paul Rouget wrote: >>> >>> The goal is to build a browser in HTML. Not to run a browser in >>> current Firefox Desktop or in Chrome. >> >> >> Ok. Are you also aiming

Re: The War on Warnings

On Wed, Jun 17, 2015 at 9:29 AM, Eric Rahm wrote: > An update on progress. I've landed bugs which should clean up ~180,000 > warnings. I have bugs pending for another ~26,000. Lovely! Thank you. The log size changes are impressive. > Top 40 sorted by top level directory: I couldn't help but no

Re: GTK3 linux builds

On 06/17/2015 08:49 AM, Martin Stransky wrote: On 06/17/2015 01:01 AM, Mike Hommey wrote: On Tue, Jun 16, 2015 at 05:57:49PM -0400, Hubert Figuière wrote: On 16/06/15 05:13 PM, Jeff Muizelaar wrote: Is there any reason not to support all the way back to the version of GTK (3.4) on the test mac

Re: GTK3 linux builds

On Wed, Jun 17, 2015 at 08:49:47AM +0200, Martin Stransky wrote: > On 06/17/2015 01:01 AM, Mike Hommey wrote: > >On Tue, Jun 16, 2015 at 05:57:49PM -0400, Hubert Figuière wrote: > >>On 16/06/15 05:13 PM, Jeff Muizelaar wrote: > >>>Is there any reason not to support all the way back to the version o

Re: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info

On 6/16/15 3:51 PM, Jeff Gilbert wrote: Ideally, we'll eventually have enough of a handle on the long tail of driver bugs that we can look at sunsetting this. We could include an entry in the blacklist download to force problematic hardware to expose this info (once we identify them as such!), wh

Re: Browser API: iframe.executeScript()

On Wed, Jun 17, 2015 at 12:02 AM, Tim Guan-tin Chien wrote: > How about the risk of having API users intentionally creating local > APIs? For example, people can implement support for apple-touch-icon> just in Gaia. > > I was told this is a concern back in B2G v1.0. I think that's fine. It's def

Re: Browser API: iframe.executeScript()

How about the risk of having API users intentionally creating local APIs? For example, people can implement support for just in Gaia. I was told this is a concern back in B2G v1.0. On Wed, Jun 17, 2015 at 5:52 AM, Jonas Sicking wrote: > On Tue, Jun 16, 2015 at 10:33 AM, Bobby Holley wrote: >>