Re: removing blank lines at beginnings and ends of JS blocks

Myk Melez wrote on 2019-01-28 09:46: This week I plan to remove blank lines at the beginnings and ends of JS blocks and update the global eslint configuration file to prohibit them by landing the patch in bug 1518283 <https://bugzilla.mozilla.org/show_bug.cgi?id=1518283>. Update: I

removing blank lines at beginnings and ends of JS blocks

Developers, This week I plan to remove blank lines at the beginnings and ends of JS blocks and update the global eslint configuration file to prohibit them by landing the patch in bug 1518283 . Note that I'm not removing all blank lines,

Re: Workflow Apropos!

James Graham wrote on 2018-11-28 13:20: On 28/11/2018 20:15, Mark Côté wrote: My team has pretty much nothing to do with the gecko GitHub clone; we need to keep our focus on the "standard" workflow. Sure, the problem is that it's an attractive nuisance for new contributors who find it and go

Re: mozilla-inbound backout policy subject to change (become similar to autoland)

Sebastian Hengst wrote on 2018-08-09 08:51: Tier 2 jobs are going to be re-evaluated if that tier is still suitable or if it's something which should not be broken because we rely on it (e.g. QuantumRender, Btup is also heading for this). Good to know, thanks, Sebastian. Is there a way to track

Re: mozilla-inbound backout policy subject to change (become similar to autoland)

Boris Zbarsky wrote on 2018-06-26 21:53: On 6/27/18 12:50 AM, Mike Hommey wrote: Perma bustage of tier-2 jobs usually do. Of a bunch of them, or of just one tier-2 job (but permanent bustage across all pushes)? My understanding was that tier-2 meant it can be broken for a bit without

Re: C++ standards proposal for a embedding library

Botond Ballo wrote on 2018-07-18 09:45: As we have some experience in the embedding space here at Mozilla, I was wondering if anyone had feedback on this embedding library proposal. This is an early-stage proposal, so high-level feedback on the design and overall approach is likely to be

Re: PSA: Major preference service architecture changes inbound

Nicholas Nethercote wrote on 2018-07-17 21:23: This is a good example of how prefs is a far more general mechanism than I would like, leading to all manner of use and abuse. "All I want is a key-value store, with fast multi-threaded access, where the keys aren't known ahead of time." Agreed, the

modifying vendored Rust crates locally

With the fixes for bug 1323557 [1] and cargo-vendor issue #71 [2], it's now more straightforward to modify a vendored Rust crate to test changes locally or on tryserver. To do so, specify the crate's vendored path in the [patch.crates-io] section of the top-level Cargo.toml file. For

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Bobby Holley 2018 March 12 at 12:25 That's not how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and the name XPConnect means "connecting Javascript to XPCOM"). But quibbling over the definition isn't really useful. I was aware that XPCOM predated

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Nicholas Nethercote 2018 March 9 at 20:02 What's your definition of XPCOM? This is basically what I'm asking Kris. I define it as the system that Firefox uses to make intra- and inter-language calls between C++ and JS via XPIDL and XPConnect. I'm interested in

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Kris Maglione 2018 March 8 at 16:22 Removing XPCOM entirely is not really a possibility. Removing XPConnect bindings entirely is... theoretically possible, but would be a monumental amount of work, and is not something I've heard anyone seriously suggest. If we

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Kris Maglione 2018 March 8 at 15:06 At any rate, I don't expect us to convert anywhere near all of our XPIDL interfaces to WebIDL. A lot of them don't need to be exposed to JS at all. A lot of those should still go away, but they don't need WebIDL bindings, just

Re: Overriding JS to allow for opening in a new tab?

Andrew Overholt 2017 October 25 at 09:41 Is there precedent for doing what a user intended which would be contrary to what the site is attempting? I recall some discussion about preventing sites from using transparent elements to block click event handling, in

Re: Reviews for in-tree documentation

Dustin Mitchell 2017 October 19 at 10:21 I think we should question the assumption that writing source-code-level documentation is a good activity for newcomers to the codebase. Documentation is usually best written by someone with a deep understanding of what is

Re: Canonical cinnabar repository

Myk Melez <mailto:m...@mykzilla.org> 2017 September 26 at 17:40 Kartikaya Gupta <mailto:kgu...@mozilla.com> 2017 September 26 at 08:49 So from the discussion here it sounds like using a full (i.e. non-grafted) cinnabar repository "just works" for most people. It has the

Re: Intent to Unship: stream decoder for BinHex format

Boris Zbarsky 2017 October 17 at 07:45 Please double-check that this use case does not get broken, or condition the code to be mailnews-only or something. Shouldn't the code rather move to comm-central if it's specific to mailnews? -myk

Re: Changes to tab min-width

Jeff Griffiths wrote: 1. do you prefer the existing behaviour or the new behaviour? I prefer the new behavior. 2. if you prefer a value for this pref different than 50 or 100, what is it? Why? I prefer a value of 0 (i.e. truly infinite tabs, never scrolling), because I distinguish tabs by

Re: Canonical cinnabar repository

Kartikaya Gupta 2017 September 26 at 08:49 So from the discussion here it sounds like using a full (i.e. non-grafted) cinnabar repository "just works" for most people. It has the problem of missing CVS history but it seems like people who need that often can use

Re: Canonical cinnabar repository

Ehsan Akhgari 2017 September 18 at 12:59 I think there is a way to have our cake and eat it too, which is enabling git-cinnabar to understand a custom mapping of SHA1 so that we can rewrite the history and have cinnabar be able to deal with that when it maps

Re: Canonical cinnabar repository

Kartikaya Gupta 2017 September 18 at 07:05 It seems to me that a lot of people are now assuming a cinnabar repo is the canonical way for git users to develop on mozilla-central. If we want to make this mozilla policy I don't really have objections, but I think that if

Re: Intent to require `mach try` for submitting to Try

James Graham 2017 September 18 at 02:56 5. Allows vanilla git and hg on the client side, but requires something complex, custom, and scary on the server side to allow pushing to either repo. Could be possible if we eliminate ~all manual pushes (i.e. everything

Re: Moving from xulrunner to firefox SDK

Manish 2017 September 6 at 05:32 Thanks Myk But I am bit confuse here. If we go by this way /path/to/firefox --app /path/to/application.ini. First there may be a possibility that Firefox is not installed and if it is installed and someone updates the

Re: Moving from xulrunner to firefox SDK

Manish 2017 August 21 at 23:53 from where can I find the latest firefox SDK version for all the platforms eg: windows, linux and mac. Second can the directory structure remains the same as earlier like for xulrunner. There isn't a Firefox SDK, as Mozilla

Re: nodejs for extensions ?

Enrico Weigelt, metux IT consult 2017 July 28 at 21:33 Hi folks, just curious: did anyone already try nodejs modules for (javascript-only) extensions ? There was some discussion of this in the dev-addons thread "Node and Web Extensions Experiment"

Re: Embedding Firefox or Gecko in 2017

cnico7 2017 July 6 at 12:47 I had the idea of using firefox with marionette protocol in order to interact with the engine and to use a custom plugin in order to hide all the design (menus, tab bars,...). This idea has many drawbacks : it is slow at launching

Re: ANN: Default bug view for BMO changed today!

> Mike Hommey > 2017 March 1 at 14:50 > 1. I often wish browsers were helpful here. Seriously. When an anchor is > close enough to the end of the page that the page can't be scrolled for > it to be at the top of the viewport, it's a PITA to find where it is. Indeed. I

Re: Embeddable Browser

Rodolpho Porto <mailto:rodolpho.po...@gmail.com> 2017 February 22 at 03:13 Hello Myk Melez, First of all, thank you for your response! I'll talk about the project, it's a kiosk-style browser, using XULRunner 24.0b10 32bit and SWT, the modifications we made were according to project

fixing bug 1190128 (was Re: Is there a reason for scrapping native.js?)

Sergey Rozhenko 2017 January 29 at 08:34 I've fixed https://bugzilla.mozilla.org/show_bug.cgi?id=1190128 in an addon because noone has ever looked at that bug Hi Sergey, Is there a reason why you haven't contributed your fix for that bug to Firefox? Bugs do

Re: What if you could reinvent Firefox theming?

Justin Dolske 2016 September 8 at 15:41 "Make things bigger" is somewhat curious... On Windows this is typically done by adjusting the display scaling factor in the OS settings. I wonder if people don't know about that, or are looking to make Firefox -- specifically --

Re: Two Factor Authentication and Github

Rok Garbas 2016 May 24 at 01:50 you can also setup github's 2fa using GAuth[1] firefox app Or use Firekey in any web browser: https://firekey.org/ -myk ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: HTML-based chrome and

Benjamin Francis 2016 February 26 at 10:16 I like this idea in theory. But I want to understand how it's different from Electron, besides simply using different underlying technology. In other words: what makes it unique that justifies the effort? Why does it even

Re: HTML-based chrome and

Benjamin Francis 2016 February 26 at 05:15 I mainly propose the change of syntax because this transition period seems like an opportunity to make a clean break, get rid of the vendor prefixes and define a long term, explicitly separate to standard HTML, chrome-only

Re: HTML-based chrome and

Ehsan Akhgari 2016 February 25 at 11:14 mozApps and the browser API are orthogonal for the most part. Removing mozApps doesn't mean that we would remove the mozbrowser API (and AFAIK that's not what Myk is planning.) Confirmed: I'm definitely *not* planning to

Re: HTML-based chrome and

Benjamin Francis 2016 February 25 at 07:18 With the demise of XULRunner it seems the only way to run a Gecko-based project that isn't Firefox is to run it on top of Firefox. That doesn't do much to "promote innovation" and I'm guessing is a major reason projects like

Re: Making it easier to file performance bugs?

David Rajchenbach-Teller 2016 February 13 at 04:50 One possible solution would be to: - add a component Firefox > Performance (and also Thunderbird > Performance, etc.) to Bugzilla, which would cover all untriaged performance issues (including web content, ux, e10s,

Re: Possible psutil bustage

On 2013/08/23 10:28, Gregory Szorc wrote: The following should get your tree in a happy state: $ hg status -in python/psutil | xargs rm If your tree is a Git mirror clone, an equivalent is: git clean -xf python/psutil -myk ___ dev-platform

Re: [b2g] Fix or disable windows desktop b2g builds

On 2013/06/07 12:39, Chris AtLee wrote: It's my understanding that the FxOS Simulator doesn't directly depend on these builds. Can anybody confirm this? I can confirm it, since I build B2G Desktop for the FxOS Simulator, and I don't depend on these builds. However, I build on the b2g18

Re: [b2g] Fix or disable windows desktop b2g builds

On 2013/06/06 20:50, Tim Chien wrote: I suggest the Apps team should aware of this and potentially invest some resource into the Windows build, if we want to fully support FxOS Simulator as a product. At least some of us on Apps are aware of it, and we've already invested some resources into