Re: Who loves multiple selection feature in editor?

> On 20 Dec 2016, at 20:52, Mats Palmgren wrote: > > The current spec editor seems open to discussing multi-range Selection, > which is encouraging. > > Perhaps we could add something like this: > > selection.forEachRange(function (range) { > // do awesome stuff > }) > > Since web developers

Re: What if you could reinvent Firefox theming?

> On 09 Sep 2016, at 00:41, Justin Dolske wrote: > > > > On Thu, Sep 8, 2016 at 8:41 AM, Jared Wein > wrote: > [...] > > Thanks for posting the results. A couple of observations... > > Why do you install themes? > [...] At 12% of responses was closer integration wi

Re: Mercurial performance (vs git)

When I use https://gist.github.com/mikedeboer/fa806e2868c5962b9741715e5fd762d5 (homegrown script that evolved over years) I get instant results. I didn’t measure its perf. It might suit your needs, it might not. It comes with

Re: Intent to ship: unprefix :dir pseudo-class

We use :-moz-locale-dir extensively in frontend code. Who will own converting that to the unprefixed version? Or, if :-moz-locale-dir is still supported after the transition period, can we discuss deprecating it in favour of unprefixed alternatives? Thanks, Mike. > On 11 May 2016, at 09:13, As

Re: Intent to enable e10s by default when running tests locally

Slightly related: since bug 1253233 landed (well, hum, the most important parts of it), it’s possible to add fully functioning elements to mochitest-chrome test windows. Since many chrome test use the pattern of adding a browser element and do stuff with it upon load, I thought this might be a

Re: Skia Content on OS X

I was also quite curious, so I started clicking up the hierarchy of that bug and ended up at: https://bugzilla.mozilla.org/show_bug.cgi?id=1154825#c1 (comment 2 is also useful info) Ultimate goal: no more checkerboarding in APZ. But Mas

Re: HTML-based chrome and

around Servo. > > Cheers, > David > > P.S.: I may be exaggerating a bit, I seem to remember that Mike De Boer > was working on his own on a project for developing applications with > Node + Gecko. > > On 27/02/16 11:11, Benjamin Francis wrote: >> I've be

Re: Decreasing quality?

I fondly remember the days when Nightly was sporting golden tabs on OSX; it’s part of the joy running the cutting edge! Cheers, Mike. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: XULRunner future and ownership

. > On 29 Jul 2015, at 23:46, Mike de Boer wrote: > > I’d like to volunteer. > > Not much more to say, really :-) > > Cheers, > > Mike. > >> On 29 Jul 2015, at 20:30, Benjamin Smedberg wrote: >> >> The Mozilla project no longer sees XULRu

Re: XULRunner future and ownership

I’d like to volunteer. Not much more to say, really :-) Cheers, Mike. > On 29 Jul 2015, at 20:30, Benjamin Smedberg wrote: > > The Mozilla project no longer sees XULRunner as a priority project. It's not > core to advancing the open web or any of our current or planned products. > > As Ben

Re: Array.concat

Hi Amit, These are called ‘Generics’ and are available in Firefox as of JavaScript 1.6 - see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods

Re: Announcing the Content Performance program

Nathan, it looks like the SessionRestore feature that was causing test failures has been removed by Tim in the meantime… Does that mean that the 'possible webcompat issues’ is the only real issue left? If so, I’d suggest to request feedback from :annevk and/ or :dbaron (for example) to get a fe

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

Re: PSA: The mochitest ise() function is dead, please use is() instead

> On 14 May 2015, at 03:15, Boris Zbarsky wrote: > > On 5/13/15 7:35 PM, Gregory Szorc wrote: >> I would steer people in the direction of Assert.jsm, specifically >> Assert.deepEqual > > This should be used very very carefully. > > As a very simple example, using this (or worse yet notDeepEqua

Re: Intent to deprecate: Insecure HTTP

> On 14 Apr 2015, at 11:42, intellectu...@gmail.com wrote: > Something entirely off-topic: I’d like to inform people that your replies to popular threads like this unsigned, with only a notion of identity in an obscure email address, makes me - and I’m sure others too - skip your message or w

Re: Project Silk on Desktop

Yeah, Jared makes a good point - exactly the reason why I reacted so enthusiastically to this announcement is that I’d never heard of Project Silk, even though I read HN (headlines, not comments ;-) ) on a daily basis. Or maybe it did, but perhaps it being all about B2G and sort of like ‘Android

Re: Project Silk on Desktop

Congratulations to all! This sounds like a massive improvement to our rendering pipeline, definitely worth of some PR effort! Is that being considered? Is this expected to have an impact on Talos numbers? I’d expect them to improve, but that probably also depends on the hardware used for the Ta

Re: Enhancing Gecko as a WebGL game platform

> On 14 Jan 2015, at 18:21, Vincent Scheib wrote: > > Artillery.com asked for features in > http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0473.html > > > They are related to Pointer Lock and notes were a

Re: Enhancing Gecko as a WebGL game platform

> On 13 Jan 2015, at 21:52, Jeff Muizelaar wrote: > > > > On Tue, Jan 13, 2015 at 10:56 AM, Mike de Boer <mailto:mdeb...@mozilla.com>> wrote: > > 2. Optionally bypass the browser compositor when a WebGL context is in > fullscreen mode. In this mode, WebGL

Re: Enhancing Gecko as a WebGL game platform

> On 13 Jan 2015, at 21:28, Till Schneidereit wrote: > > On Tue, Jan 13, 2015 at 8:24 PM, Luke Wagner wrote: > >>> Do you know what they actually mean when they use the term "hardware >>> pointer"? >>> >> >> I believe what he's referring to is the type of hardware-accelerated cursor >> suppo

Re: Enhancing Gecko as a WebGL game platform

> On 13 Jan 2015, at 18:23, Ehsan Akhgari wrote: > > On 2015-01-13 10:56 AM, Mike de Boer wrote: >> Hi all, >> >> I’ve been having interesting discussions with a WebGL game developer, whose >> employer is betting big on the Web Platform as the foundation

Enhancing Gecko as a WebGL game platform

Hi all, I’ve been having interesting discussions with a WebGL game developer, whose employer is betting big on the Web Platform as the foundation for their games currently in development. I asked him what the most interesting features and improvements would be to allow them to keep betting on t

Re: Who wishes to discuss test suites at MozLandia?

Excellent idea, I’m in! https://www.youtube.com/watch?v=Dj3GH5myc3M I’d like to discuss ways to move https://bugzilla.mozilla.org/show_bug.cgi?id=867742 forward, for example. Cheers, Mike. >

Re: e10s is now enabled by default for Nightly!

I had to file https://bugzilla.mozilla.org/show_bug.cgi?id=1095496 :( Mike. > On 07 Nov 2014, at 17:33, Gijs Kruitbosch wrote: > > On 07/11/2014 16:26, Dave Townsend wrote: > >> wrote: >> >>> Where can we read about how this decision was made? On my profiles with >>> Force RTL, e10s perma-c

Re: Async Transaction Manager: needs home, reviewers

> On 01 Nov 2014, at 20:50, Kyle Huey wrote: > > On Sat, Nov 1, 2014 at 12:42 PM, wrote: >> The reviewer should understand asynchronous Promise operations, preferably >> the OS.File promises > > We shouldn't be landing new code that uses Promise.jsm in mozilla-central. Well, that surely has

Re: Under win32 with xulrunner with addon-sdk, there is weird printf, how to avoid this.

You mean the ASCII escape sequences? You can find and disable them by editing the console.js file in the build template: https://github.com/mikedeboer/chromeless2/blob/master/lib/build/templates/xulrunner.template/components/console.js

Re: Moratorium on new XUL features

This is one of the reasons I started to breathe new life in the Chromeless project[1], but with a grander scope this time around. I’d like to facilitate a pragmatic migration route to building desktop apps with XULRunner using only the latest Web technologies, including asm.js and WebGL+WebVR.

Fwd: JavaScript (strict) Warning from FF mochitest-plain test.

FYI, forwarding Ehsan’s reply: Begin forwarded message: > From: Ehsan Akhgari > Subject: Re: JavaScript (strict) Warning from FF mochitest-plain test. > Date: 2 Oct 2014 23:09:29 GMT+2 > To: Mike de Boer > > Great! I'm all for this if we decide to act on the data. :

Re: JavaScript (strict) Warning from FF mochitest-plain test.

> Are we going to spend the time to fix these, however? I’d be up for that, certainly! > For context, for as long as I remember, if you kept the browser console open > and used the browser, we'd occasionally report an unhandled chrome JS errors > (for example when attempting to access propert

Re: JavaScript (strict) Warning from FF mochitest-plain test.

Thanks for bringing this up! So ever since extra super awesome strict warning were turned on we indeed have to endure longer tail logs during test runs and when running debug builds. Just like I get the information telling me which video card my computer has for about the 1000th time. All in a

Re: Deprecating localstore.rdf

On 23 Jul 2014, at 14:10, rviti...@mozilla.com wrote: > Localstore.rdf will soon be replaced with a json store (see Bug 559505). I am > currently planning to leave the localstore.rdf implementation as it is and > issue a warning when a client tries to access to it. This is needed as some > add-

Re: How does xpcshell unittest are runned

Error code 3, for me, always meant that I made a typo in head.js - or other JS files loaded other than the test file itself - that caused a SyntaxError. It’s unfortunate that there’s no better error reporting during loading and evaluation of JS while loading the harness, so I needed to resort to

Re: Are you interested in doing dynamic analysis of JS code?

On 25 Jun 2014, at 20:04, Fitzgerald, Nick wrote: > > Record/replay is such a holy grail (eclipsed only by "time traveling" / > reverse and replay interactive (as opposed to a static recording) debugging > with live, on-stack code editing) that I hesitate to even get my hopes up… Oh, the joy I

Re: Standardized assertion methods

On 05 Jun 2014, at 12:00, Dao wrote: > On 05.06.2014 11:38, Mike de Boer wrote: >> On 05 Jun 2014, at 09:54, Dao wrote: >> >>> On 04.06.2014 11:45, Mike de Boer wrote: >>>> The reason CommonJS came into view was not because of it’s semantic >>>&g

Re: Standardized assertion methods

On 05 Jun 2014, at 09:54, Dao wrote: > On 04.06.2014 11:45, Mike de Boer wrote: >> The reason CommonJS came into view was not because of it’s semantic >> superiority, but because of its similarity to both the XPCShell-test and >> Mochitest assertion styles and implemen

Re: Standardized assertion methods

On 04 Jun 2014, at 19:20, Ehsan Akhgari wrote: > On 2014-06-04, 5:45 AM, Mike de Boer wrote: >> On 04 Jun 2014, at 00:33, James Graham wrote: >> >>> On 03/06/14 20:34, Boris Zbarsky wrote: >>> >>>> I'm arguing against Assert.jsm using the com

Re: Standardized assertion methods

On 04 Jun 2014, at 00:33, James Graham wrote: > On 03/06/14 20:34, Boris Zbarsky wrote: > >> I'm arguing against Assert.jsm using the commonjs API names. > > And I am arguing against using the CommonJS semantics. If we are adding > new assertions it shouldn't be ones that encourage broken tests

Re: Standardized assertion methods

On 03 Jun 2014, at 17:39, Ehsan Akhgari wrote: > On 2014-06-02, 9:35 PM, Boris Zbarsky wrote: >> On 6/2/14, 5:33 PM, Gavin Sharp wrote: >>> Do either of you have reasoning for that other than "it looks better >>> to me"? >> >> My personal experience is that when I try to write xpcshell tests the

Re: Standardized assertion methods

James, thanks so much for the additional background information about testing at Mozilla. I’m currently following the bugs you mentioned earlier and am looking forward to their results! Mike. On 03 Jun 2014, at 16:07, James Graham wrote: > On 03/06/14 14:16, Mike de Boer wr

Future improvements to Javascript unit-test runners (was: Standardized assertion methods)

ou're missing > from node/mocha. > > If you think that needs its own topic, feel free to fork the summary. > > In any case, discussions about the ease of use of our test framework(s) seem > eminently on-topic for m.d.platform. > > ~ Gijs > > On 03/06/2014 1

Re: Standardized assertion methods

I understand all that and I *think* you missed the header mentioning I was going off-topic… Mike. On 03 Jun 2014, at 15:39, Gijs Kruitbosch wrote: > On 03/06/2014 14:16, Mike de Boer wrote: >> Indeed, I’m used to the NodeJS/ Mocha flow of writing tests as fast, or even >> fas

Re: Standardized assertion methods

On 03 Jun 2014, at 14:50, Boris Zbarsky wrote: > On 6/3/14, 6:22 AM, Mike de Boer wrote: >> Their lack of modularity costs us flexibility in adopting and/ or promoting >> TDD development. > > Mike, I'm very curious about this part. Do you have a link offhand to a mo

Re: Standardized assertion methods

On 03 Jun 2014, at 15:07, Boris Zbarsky wrote: > On 6/3/14, 8:50 AM, Boris Zbarsky wrote: >> I do think we should be very intentional about adopting something new, >> both in terms of semantics (mochitest is() using == is a mistake we >> should not duplicate in the short-name comparison function

Re: Standardized assertion methods

On 03 Jun 2014, at 14:54, Boris Zbarsky wrote: > On 6/3/14, 8:39 AM, Mike de Boer wrote: >> I think it helps provide a common, immediate understanding for new >> contributors who’d like to write test for the code they contribute, as the >> add-on SDK and the NodeJS com

Re: Standardized assertion methods

write test for the code they contribute, as the add-on SDK and the NodeJS community already use it exclusively. On 03 Jun 2014, at 13:49, Gijs Kruitbosch wrote: > On 03/06/2014 12:27, Mike de Boer wrote: >> >>>> 5. Assertion semantics are indeed poorly specified, across the b

Re: Standardized assertion methods

Please see my comments inline. On 03 Jun 2014, at 12:57, James Graham wrote: > I'm not sure I grasp your overall point, but I have a few comments. > > On 03/06/14 11:22, Mike de Boer wrote: >> 1. The `Assert.*` namespace is optional and may be omitted. This >> mod

Re: Standardized assertion methods

1. The `Assert.*` namespace is optional and may be omitted. This module is also present in the addon-sdk and used _with_ that namespace, usually with a lowercase `assert.*`. Please pick whatever suits your fancy. 2. testharness.js, Mochitest, XPCShell’s head.js and other suite-runners that we u

Re: Standardized assertion methods

On 02 Jun 2014, at 17:39, Paolo Amadini wrote: > > Have you considered requiring test cases to use the the "Assert." > namespace explicitly? I would find that style more readable, and also > assertions easier to find when scanning the code. And they're still > shorter than current assertion funct

Re: Standardized assertion methods

ul for that. > > > On Mon, Jun 2, 2014 at 12:37 PM, Mike de Boer wrote: > Dear unit test writers, > > As a happy few of you might already know, we introduced a standalone, > versatile class of assertion methods with Assert.jsm[1], which implements the > CommonJS Unit Testi

Standardized assertion methods

Dear unit test writers, As a happy few of you might already know, we introduced a standalone, versatile class of assertion methods with Assert.jsm[1], which implements the CommonJS Unit Testing specification version 1.1[2]. These methods were already available to you in the global `Assert` name

Re: e10s: don't call it a comeback

I _almost_ did a little dance in my room to celebrate this news, it’s such a valuable project for Firefox! Please sign me up for any find bar related bugs, Tom and I worked on it before anyways. Go get ‘em and… have fun! Mike. On 21 May 2014, at 09:11, Chris Peterson wrote: > In case you mi

Re: Argument validation as a JSM?

I agree with what David said; it usually makes the code harder to read, but that also greatly depends on the exposed API of the library. Assertions are a widely-known, commonly accepted way to do in-method validation. I quite recently wrote Assert.jsm (http://dxr.mozilla.org/mozilla-central/sou

Re: [b2g] Relevance of Super-Review (Was: Hardening the review requirements for changing .webidl files)

Another rather nice purpose for the s-r flag, in my experience, is exposed during onboarding of fresh, remote, engineers (like I was ~1 year ago): it allowed me to get acquainted with the review cycle while working on Good Next Bugs(tm) that touched intricate parts of the codebase, like DocShell

Re: Oculus VR support & somehwat-non-free code in the tree

I’d like to add voice to Henri’s opinion here, because it’s important. The pivotal part of this discussion is about the precedent this establishes and the long-term repercussions it will have. On 15 Apr 2014, at 02:35, Vladimir Vukicevic wrote: > Yes -- perhaps unsurprisingly, I disagree with G

Re: JavaScript Style Guide. Emacs mode line.

Awesome idea! It also supports per-directory settings, so a style difference for any module can be recorded as well. Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=957564 Whatever comes out of these discussions, they can be recorded & enforced with this in-tree and not just in a wiki. C

Re: [RFC] Should we persist dynamically generated iframes?

Perhaps we could take a nuanced version of this option... > Or we could not save dynamic iframes that are not visible. …changing it to ‘Put a reasonable cap on the amount of history we store for invisible, dynamic iframes, using a fifo queue’? Mike. On Nov 13, 2013, at 2:09 PM, David Rajchenba

Re: Removal of native notification systems on desktop platforms

On Oct 12, 2013, at 2:50 PM, Philip Chee wrote: > On 09/10/2013 09:14, Marco wrote: > >> It's not entirely clear to me why libnotify support was removed, the >> author of the patch stated: >> "I removed Growl support because it does not support features needed to >> implement the spec. I also

Re: How to check if an element is visible...

On Sep 13, 2013, at 10:00 PM, "Robert O'Callahan" wrote: > On Fri, Sep 13, 2013 at 7:25 AM, Benjamin Smedberg > wrote: > This is a hard problem, and it depends on what question you're asking: > > * Is a node visible if it's in the window but some other window is covering > the current window

How to check if an element is visible...

…reliably from C++? Some background: in bug 257061 I'm implementing to count and display the number of found items in the findbar. Gavin mentions in https://bugzilla.mozilla.org/show_bug.cgi?id=257061#c88 that there has to be some prior art related to checking if an element/ node is currently v

Re: Proposal to make Firefox open in the foreground on Mac when launched from terminal

I vote for foreground as a default as well! ++ On May 30, 2013, at 1:40 AM, Ehsan Akhgari wrote: > On 2013-05-29 6:45 PM, André Reinald wrote: >> I think the default behavior should stay as it is. >> But I suggest having the mach script read a setting (from mozconfig or >> elsewhere) to decide w

Re: Code Review Session

How about integrating it into BugzillaJS? I'm working on it quite a lot now (https://github.com/gkoberger/BugzillaJS/pull/77 and https://github.com/gkoberger/omnium/pull/3) to make some improvements to Bugzilla 'core'. I think an add-on that eventually is good enough to use for Mozillians woul

Re: Simplify async code-flows and unify unit tests

-tests, but for any JS unit test now and in the future. In that sense I'm also not trying to 'push' AsyncTest.jsm, it's merely something I wrote & documented for general use that might fit the bill. > /Sam > > On Tuesday, May 7, 2013 2:49:49 PM UTC+1, Mike de Bo

Re: Simplify async code-flows and unify unit tests

Hi Joshua! Thanks for taking the time to read and reply! Please read my answers inline... On May 8, 2013, at 6:17 AM, Joshua Cranmer 🐧 wrote: > On 5/7/2013 8:49 AM, Mike de Boer wrote: >> I've told some of you before that I'm not a big fan of Promise libraries (if >>

Re: Simplify async code-flows and unify unit tests

temporarily. I might've explained that poorly! I merely wanted to point out we can do so much more to promote TDD-style development. Again, thanks for your time, Mike. On May 8, 2013, at 4:04 AM, Mark Hammond wrote: > On 7/05/2013 11:49 PM, Mike de Boer wrote: >> TLDR; in bug

Simplify async code-flows and unify unit tests

~100 lines), but the more significant improvement here is the structure that is proposed as uniform. To top this off, you can set a flag in each suite: notify: true to present you with a Growl notification once the suite is done to report the results! That shows that this library is meant to bring back the fun into creating unit tests. Mike de Boer.___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: smartmake-like functionality has landed in mach

I think it's much more an issue on Windows; there you need to build browser each and every time. On May 3, 2013, at 9:27 AM, Dave Townsend wrote: > On 5/3/2013 12:21 AM, Mike Hommey wrote: >> On Fri, May 03, 2013 at 02:55:09AM -0400, Ehsan Akhgari wrote: Does it also build browser/app on O

Re: Storage in Gecko

I have to admit; I've been thinking about this as well… and considering the complexities involved with developing algorithms to deal with caches, fsyncs and concurrency I tend to lean toward NOT rolling your own, but instead look at what's out there. Event though it's oriented towards server us

Changed behavior: writing to console.log file

Hi all, Since https://bugzilla.mozilla.org/show_bug.cgi?id=833939 recently landed on central, I'd like to inform you all of its implications: * Debug builds no longer write the logs to a file called `console.log` in the users' AppData directory (for example `~/Library/Application Support/Fire