Re: A less intrusive way to run mochitest-plain

[Blake Kaplan]

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
https://lists.mozilla.org/listinfo/dev-platform

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

[Botond Ballo]

> 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:

https://botondballo.wordpress.com/2017/11/20/trip-report-c-standards-meeting-in-albuquerque-november-2017/

Cheers,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

A less intrusive way to run mochitest-plain

[Brendan Dahl]

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 --headless [path/to/test/]

A few notes:

- Headless mode tries to mimic native platform behavior, but it's not
possible in all cases. Tests meant to exercise code in the
widget/ directory (e.g. window size changes, clipboard events,
etc) may have slightly different behavior than the native widget code and
should be tested in both headless and normal mode.

- Issues with headless mode should be filed under Firefox->Headless [1]

- Headless mochitest-plain tests are also running in automation. On
TaskCluster they show up as h<#>.

- We could potentially start running mochitests in parallel and I’ve filed
a bug [2] to look into that.

-Brendan

[1]
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Headless

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1419135
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Joseph Hildebrand]

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  
>> wrote:
>> 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?
>> >
>> > 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 object in order to test it; you 
>> > can pass your own part-mocked Object instance into whatever mechanism is 
>> > trying to call `Object.foo`.
>> >
>> > In your `foo`/`bar` case, you'd pass a `MockObject` to `bar`, and verify 
>> > that `MockObject.foo` was called. We do this all the time in codebases 
>> > that use less dynamic languages (e.g., Fennec and Firefox for iOS).
>> >
>> > This doesn't help you to test existing singleton-based JS code… but then, 
>> > if that code is already using Object.freeze, then you already can't, and 
>> > you'll be having to change _something_.
>> >
>> > I mostly agree with Nicolas's sentiment; poking at the guts of code 
>> > outside your own module (or even in your own module!) isn't really a kind 
>> > of software development that I feel we should encourage. If we find that 
>> > gut-poking is the only good way to write tests for a component, then I 
>> > would rather we revisit the design of the component instead of making it 
>> > mutable. Refactoring for testability is A-OK in my book.
>> > ___
>> > firefox-dev mailing list
>> > firefox-...@mozilla.org
>> > https://mail.mozilla.org/listinfo/firefox-dev
>> 
>> —
>> Joe Hildebrand
>> 
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: constructible EventTarget

[Boris Zbarsky]

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 precisely that 
reason.  :(


I can't find any existing open issues on this, though I was sure there 
were some.  Ah, well, filed 
https://github.com/devtools-html/debugger.html/issues/4750


I was thinking more of these, ie the watch expressions and/or variables 
(locals/scopes) view and the console.


Filed https://github.com/devtools-html/debugger.html/issues/4751 for the 
former and https://bugzilla.mozilla.org/show_bug.cgi?id=1419089 for the 
latter.


This would be useful even without these "custom" EventTargets, because 
it could be used for XHR objects and whatnot...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: constructible EventTarget

[Gijs Kruitbosch]

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 
"subclasses").


Hmm.  So there are at least three possible things you might be asking 
for here:


1)  In the existing debugger "events" view, include EventTargets other 
than windows and nodes.


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. If it still 
exists, yes, that would be nice.


2)  When examining an object that happens to be an EventTarget in the 
console, provide some UI to see its event listeners (similar to the "ev" 
marker on nodes in the inspector).


3)  When examining an object that happens to be an EventTarget in the 
debugger (e.g. in the watch expression window?  Where else?) provide 
some UI to see its event listeners.


Was it one of those?  Or something else?


I was thinking more of these, ie the watch expressions and/or variables 
(locals/scopes) view and the console.


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Tom Schuster]

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 9:00 AM, Richard Newman  wrote:
> >
> > 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 object in order to test it; you can
> pass your own part-mocked Object instance into whatever mechanism is trying
> to call `Object.foo`.
> >
> > In your `foo`/`bar` case, you'd pass a `MockObject` to `bar`, and verify
> that `MockObject.foo` was called. We do this all the time in codebases that
> use less dynamic languages (e.g., Fennec and Firefox for iOS).
> >
> > This doesn't help you to test existing singleton-based JS code… but
> then, if that code is already using Object.freeze, then you already can't,
> and you'll be having to change _something_.
> >
> > I mostly agree with Nicolas's sentiment; poking at the guts of code
> outside your own module (or even in your own module!) isn't really a kind
> of software development that I feel we should encourage. If we find that
> gut-poking is the only good way to write tests for a component, then I
> would rather we revisit the design of the component instead of making it
> mutable. Refactoring for testability is A-OK in my book.
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
>
> —
> Joe Hildebrand
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: constructible EventTarget

[Boris Zbarsky]

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 possible things you might be asking 
for here:


1)  In the existing debugger "events" view, include EventTargets other 
than windows and nodes.


2)  When examining an object that happens to be an EventTarget in the 
console, provide some UI to see its event listeners (similar to the "ev" 
marker on nodes in the inspector).


3)  When examining an object that happens to be an EventTarget in the 
debugger (e.g. in the watch expression window?  Where else?) provide 
some UI to see its event listeners.


Was it one of those?  Or something else?

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Wade]

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  wrote:
> 
> On Sat, Nov 18, 2017 at 7:38 AM,  mailto:w...@vapor4life.com > wrote:
> 
> > > 57 is unusable for me..I keep 35-50 tabs open at any given time 
> and I used Custom Tab Width legacy extension to prevent scrolling. I CANNOT 
> stand scrolling thru tabs. I don't need to read the tab- I KNOW where they 
> are. It should be simple to allow tabminwidth to go lower than currently 
> configured. Then the user could decide how THEY like it. If this doesn't 
> happen soon I will be reverting to an older versio nof FF or switching 
> browsers altogether. btw..there is still some memory leak with FF. After a 
> day I have to restart FF or it would eat all remaining Mem on my 8G system.
> > 
> > > 
> Luckily, Firefox has your back. From the first message in this thread:
> 
> On Tuesday, October 3, 2017 at 3:36:40 PM UTC-5, Jeff Griffiths wrote:
> > 1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
> > contains a pixel value that controls the minimum width of a tab.
> 
> Which you can easily set to a different value that works better for you.
> 
> Cheers,
> 
> Dirkjan
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Cornel Ionce]

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:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1416728 
Pinterest redirects to wrongly dimensioned versions of photos/articles
Core
DOM
	YES 
 
	Nika Layzell 

1416721 
[twitch] The buttons glitch as long as you hover the cursor over them
Core
Layout
TBD NOBODY
1417928 
	The Title and the Taskbar icons are a bit low dpi (150% and 175%) while 
the installer is running

Firefox
Installer
TBD NOBODY


*BETA CHANNEL
*

**
ID  Summary Product Component   Is a regression 
Assigned to
1417016 
Location bar overlaps the "tip" notification box
Firefox
Address Bar
	YES 
 
	NOBODY

1417036 
"Save to Pocket" drop down menu glitches
Firefox
Pocket
	YES 
 
	Drew Willcoxon 


*
NIGHTLY CHANNEL**
*


ID  Summary Product Component   Is a regression 
Assigned to
1417014 
	[Form Autofill] - Credit Card fields are not filled in the first time a 
profile is selected after un-checking and checking the Autofill credit 
card box

Toolkit
Form Autofill
NO  Luke Chang 


*ESR CHANNEL*
none


Regards,
Cornel (:cornel_ionce)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Joe Hildebrand]

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?
> 
> 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 object in order to test it; you can 
> pass your own part-mocked Object instance into whatever mechanism is trying 
> to call `Object.foo`.
> 
> In your `foo`/`bar` case, you'd pass a `MockObject` to `bar`, and verify that 
> `MockObject.foo` was called. We do this all the time in codebases that use 
> less dynamic languages (e.g., Fennec and Firefox for iOS).
> 
> This doesn't help you to test existing singleton-based JS code… but then, if 
> that code is already using Object.freeze, then you already can't, and you'll 
> be having to change _something_.
> 
> I mostly agree with Nicolas's sentiment; poking at the guts of code outside 
> your own module (or even in your own module!) isn't really a kind of software 
> development that I feel we should encourage. If we find that gut-poking is 
> the only good way to write tests for a component, then I would rather we 
> revisit the design of the component instead of making it mutable. Refactoring 
> for testability is A-OK in my book.
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

— 
Joe Hildebrand

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Richard Newman]

>
> 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 object in order to test it; you can
pass your own part-mocked Object instance into whatever mechanism is trying
to call `Object.foo`.

In your `foo`/`bar` case, you'd pass a `MockObject` to `bar`, and verify
that `MockObject.foo` was called. We do this all the time in codebases that
use less dynamic languages (e.g., Fennec and Firefox for iOS).

This doesn't help you to test existing singleton-based JS code… but then,
if that code is already using Object.freeze, then you already can't, and
you'll be having to change _something_.

I mostly agree with Nicolas's sentiment; poking at the guts of code outside
your own module (or even in your own module!) isn't really a kind of
software development that I feel we should encourage. If we find that
gut-poking is the only good way to write tests for a component, then I
would rather we revisit the design of the component instead of making it
mutable. Refactoring for testability is A-OK in my book.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Mark Banner]

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 JavaScript developer that they 
should use these functions, in web pages, in JavaScript libraries, …


I believe that Object.freeze and Object.seal are sanity functions, 
part of defensive programming, used to guarantee that no other part of 
the code is doing something which is not intended.
I can understand the idea here, but I'm failing to believe that doing 
this would outweigh the benefits of having a unit test system where I 
can truly test at the unit level (or, more easily test at the 
integration/functional level).


If we had a complex function bar(), which, as part of it called 
Object.foo, how could I ensure that Object.foo is called with the 
correct parameters according to the inputs of bar()?


If Object is frozen, then I can't change Object, which means I either 
have to have some sort of abstraction interface, or a backdoor into 
Object, both of which would add extra overhead and complexity which 
doesn't seem to be the ideal.


Are there alternative ways we could achieve the same without the (or 
with low) complexity/overhead?


Mark.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Nicolas B. Pierron]

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 functions, in web pages, in JavaScript libraries, …


I believe that Object.freeze and Object.seal are sanity functions, part of 
defensive programming, used to guarantee that no other part of the code is 
doing something which is not intended.


While you might think that the other parts of the code are exclusively 
addons.  I will suggest that the other parts of the code start no further 
than 20 lines below in the same file.


Also, I will note that Object.freeze and Object.seal have the potential of 
offering more room for optimization in a JIT compiler.  Currently we are not 
doing it in SpiderMonkey, but we could definitely improve the generated code 
based on freeze & seal properties.


--
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: constructible EventTarget

[Gijs Kruitbosch]

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 EventTarget (or any "subclasses").


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Gijs Kruitbosch]

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 add-ons, i.e. stop them messing with our 
internal interfaces. Now that this isn't a problem, it seems that we 
should reconsider this.


One of the main reasons for opening this up would be to allow easier 
stubbing for unit/integration tests. For example, using sinon with 
stubbing makes it easier to work with - you don't have to cover multiple 
components for a "simple" test if you don't want to. Unfortunately, the 
current practice for using Object.freeze/Object.seal prevents this.


Are there any concerns or objections to changing this practice?


Thanks for raising this, I think this is a great idea. I think 
additionally we could probably drop a lot of internal/external object 
forwarding we do for this purpose (e.g. CustomizableUI has that and a 
CustomizableUIInternal object to which everything is forwarded), which 
would remove a lot of useless boilerplate.


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Mark Banner]

[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 add-ons, i.e. stop them messing with our 
internal interfaces. Now that this isn't a problem, it seems that we 
should reconsider this.


One of the main reasons for opening this up would be to allow easier 
stubbing for unit/integration tests. For example, using sinon with 
stubbing makes it easier to work with - you don't have to cover multiple 
components for a "simple" test if you don't want to. Unfortunately, the 
current practice for using Object.freeze/Object.seal prevents this.


Are there any concerns or objections to changing this practice?

Mark.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Mark Banner]

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 
internal interfaces. Now that this isn't a problem, it seems that we 
should reconsider this.


One of the main reasons for opening this up would be to allow easier 
stubbing for unit/integration tests. For example, using sinon with 
stubbing makes it easier to work with - you don't have to cover multiple 
components for a "simple" test if you don't want to. Unfortunately, the 
current practice for using Object.freeze/Object.seal prevents this.


Are there any concerns or objections to changing this practice?

Mark.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform