Re: A less intrusive way to run mochitest-plain

Brendan Dahl wrote: > ./mach test --headless [path/to/test/] This is really awesome, I can't wait to use it! -- Blake Kaplan ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Upcoming C++ standards meeting in Albuquerque, New Mexico

> The next meeting of the C++ Standards Committee will be November 6-11 > in Albuquerque, New Mexico. If you're interested in what happened at this meeting, my blog post about it is now live:

A less intrusive way to run mochitest-plain

I just landed support for running mochitest-plain tests in headless mode. Next time you want to run some mochitests and not be bothered by Firefox opening and demanding focus, just add ---headless to ./mach test. Headless mochitest-plain is supported on Windows, MacOS, and Linux. ./mach test

Re: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

Tests seem like a reasonable place to take a perf trade off though, right? Mobile/terse. DYAC. > On Nov 20, 2017, at 10:29 AM, Tom Schuster wrote: > > Please don't use proxies unnecessarily. They are bad for performance. > >> On Mon, Nov 20, 2017 at 5:05 PM, Joe Hildebrand

Re: Intent to implement and ship: constructible EventTarget

On 11/20/17 12:26 PM, Gijs Kruitbosch wrote: I don't see the "events" view in the current debugger in 57/58/59 anymore, but perhaps I'm not looking in the right place. Oh, right, it's not implemented in the new debugger yet... I keep forgetting that I have the new debugger disabled for

Re: Intent to implement and ship: constructible EventTarget

On 20/11/2017 17:13, Boris Zbarsky wrote: On 11/20/17 6:28 AM, Gijs Kruitbosch wrote: Devtools' inspector lets you see which DOM nodes have event listeners attached to them. It would be neat if they could provide the same support in the debugger for instances of EventTarget (or any

Re: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

Please don't use proxies unnecessarily. They are bad for performance. On Mon, Nov 20, 2017 at 5:05 PM, Joe Hildebrand wrote: > You could also potentially use a Proxy object: > > https://gist.github.com/hildjj/1ac6e3d52e4e0d23f6289d73c1840a5a > > > On Nov 20, 2017, at

Re: Intent to implement and ship: constructible EventTarget

On 11/20/17 6:28 AM, Gijs Kruitbosch wrote: Devtools' inspector lets you see which DOM nodes have event listeners attached to them. It would be neat if they could provide the same support in the debugger for instances of EventTarget (or any "subclasses"). Hmm. So there are at least three

Re: Changes to tab min-width

I am aware of browser.tabs.tabMinWidth but it seems to have a minimum of 40 or 50. Setting it lower has no affect. This was the point of my message. I would like to set it to 10 or 15 or even 0 for infinite shrinking. Wade > On November 18, 2017 at 1:22 AM Dirkjan Ochtman

[Firefox Desktop] Issues found: November 13th to November 17th

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA Team last week, *November 13 - November 17* (week 46). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

You could also potentially use a Proxy object: https://gist.github.com/hildjj/1ac6e3d52e4e0d23f6289d73c1840a5a > On Nov 20, 2017, at 9:00 AM, Richard Newman wrote: > > Are there alternative ways we could achieve the same without the (or with > low) complexity/overhead? >

Re: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

> > Are there alternative ways we could achieve the same without the (or with > low) complexity/overhead? > If I'm understanding correctly what you're trying to do, the typical suggestion here is to not use global singletons. That way you don't need to dig into the guts of a globally visible

Re: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

On 20/11/2017 13:22, Nicolas B. Pierron wrote: On 11/20/2017 10:01 AM, Mark Banner wrote: Now that we don't have legacy add-ons outside of our control, I would like to propose that we stop using Object.freeze/Object.seal on most of our objects. I would personally recommend to every

Re: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

On 11/20/2017 10:01 AM, Mark Banner wrote: Now that we don't have legacy add-ons outside of our control, I would like to propose that we stop using Object.freeze/Object.seal on most of our objects. I would personally recommend to every JavaScript developer that they should use these

Re: Intent to implement and ship: constructible EventTarget

On 19/11/2017 03:55, Boris Zbarsky wrote: Devtools bug: I don't think devtools need to do anything special here. Devtools' inspector lets you see which DOM nodes have event listeners attached to them. It would be neat if they could provide the same support in the debugger for instances of

Re: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

On 20/11/2017 10:01, Mark Banner wrote: Now that we don't have legacy add-ons outside of our control, I would like to propose that we stop using Object.freeze/Object.seal on most of our objects. I believe that this was originally done to provide some extra security/stability relating to

Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

[Resending to get the correct Firefox list] Now that we don't have legacy add-ons outside of our control, I would like to propose that we stop using Object.freeze/Object.seal on most of our objects. I believe that this was originally done to provide some extra security/stability relating to

Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

Now that we don't have legacy add-ons outside of our control, I would like to propose that we stop using Object.freeze/Object.seal on most of our objects. I believe that this was originally done to provide some extra security/stability relating to add-ons, i.e. stop them messing with our