Intent to Prototype: CSS Masonry layout

[Mats Palmgren]

Summary: Masonry layout is a popular idea of how to lay out content on
the web, e.g. a Pinterest wall of images. I've made a detailed proposal
on how to support this natively as feature of CSS Grid here:
https://github.com/w3c/csswg-drafts/issues/4650
The feedback has been overwhelmingly positive so far and the CSSWG has
resolved to adopt the proposal.  So I intend to implement a prototype of
this and enable it in Nightly for testing/feedback as we develop this
feature.

Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1607954
Standard: TBD
Platform coverage: all
Preference: layout.css.grid-template-masonry-value.enabled
DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1607971


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

Upcoming C++ standards meeting in Prague

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee (WG21) will be
February 10-15 in Prague, Czech Republic.

This meeting will continue to focus on bug fixing and stabilization
for C++20, which has achieved feature-complete status in July 2019,
and whose Draft International Standard (technically complete draft
document, including bug fixes) we hope to approve for publication by
the end of the meeting. C++20 is a big release, so we want to make
sure we get it right. In parallel, the Evolution groups will be
increasingly looking at C++23 material. The committee's proposed
high-level direction for C++23 can be found here [1], with significant
items including contracts, networking, reflection, and pattern
matching.

If you're curious about the state of C++ standardization, I encourage
you to check out my blog posts where I summarize each meeting in
detail (most recent one here [2]), and the list of proposals being
considered by the committee (new ones since the last meeting can be
found here [3] and here [4]).

I will be attending this meeting, splitting my time between the
Evolution Working Group Incubator (which I'll be continuing to chair),
and the Evolution Working Group itself (on days when the Incubator
isn't running), perhaps also visiting the Reflection Study Group if
time permits.

If you have any questions about the upcoming meeting, feedback on any
of the proposals, or just want to chat about C++ standardization in
general, please feel free to reach out! I'm all the Berlin All Hands,
so if you're here too, feel free to find me in person to chat.

Cheers,
Botond

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0592r4.html
[2] 
https://botondballo.wordpress.com/2019/11/15/trip-report-c-standards-meeting-in-belfast-november-2019/
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-11
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/#mailing2020-01
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Removing support for non-nsISupports XPIDL interfaces

[Andrew McCreight]

In times of old, you could declare an XPIDL interface that didn't inherit
from nsISupports, as long as it only had constants in it. I'm not sure why
it was really such a burden to make it inherit from nsISupports. Anyways,
it appears that our de-COM efforts have proceeded far enough that this
feature is not needed any more, so I am removing support for it in bug
1611173. If you do have such an interface, it will fail to compile. You
should be able to fix it by making the interface inherit from nsISupports.

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

[desktop] Bugs logged by Desktop Release QA in the last 7 days

[Mihai Boldan]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team in the last 7 days.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/yfwt3p5x.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: Address Bar
* ASSIGNED - https://bugzil.la/1610497 - Address bar can not be selected 
by mouse if the browser has the minimum width


Firefox: New Tab Page
* NEW - https://bugzil.la/1610812 - Context menu is displayed wrong (on 
the right side) for the last Highlight from a row again


Firefox: Preferences
* NEW - https://bugzil.la/1610318 - Preferences/Options being opened 
with subcategories have a "useless" back button entry added (e.g. The 
Manage Settings button from about:protections and the privacy protection 
entry in the hamburger menu)


Core: Networking: DNS
* NEW - https://bugzil.la/1610834 - When mode 3 is enabled the login 
page for a captive portal can't be reached


Core: Print Preview
* NEW - https://bugzil.la/1610310 - Google drive pdf documents are 
displayed badly if document is not downloaded before using print preview


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/sqcftp7.


Regards,
Mihai Boldan


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

Re: Proposed W3C Charter: WebAssembly Working Group

[Luke Wagner]

I've been involved in the re-drafting of this charter as part of the
regular wasm WG meetings and I think we should support it.

Cheers,
Luke

On Tue, Jan 21, 2020 at 11:10 AM L. David Baron  wrote:

> The W3C is proposing a revised charter for:
>
>   WebAssembly Working Group
>   https://www.w3.org/2020/01/wasm-wg-charter-2020-proposed.html
>   https://lists.w3.org/Archives/Public/public-new-work/2020Jan/0003.html
>
> The differences from the previous charter are:
>
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F08%2Fwasm-charter=https%3A%2F%2Fwww.w3.org%2F2020%2F01%2Fwasm-wg-charter-2020-proposed.html
>
> Mozilla has the opportunity to send comments or objections through
> Thursday, February 13.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.  (We should probably say something, even if
> it's just support, given our involvement.)
>
> -David
>
> --
> 턞   L. David Baronhttps://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Volunteers needed for nightly crash triage rotation

[Gabriele Svelto]

[cross-posting to firefox-dev and stability]

Due to the recent layoffs the nightly crash triage roster has a lot of
holes so if you have some spare cycles please come and help out!

Nightly crash triage consists in looking at the crashes for a specific
version of nightly (e.g. the previous week Monday build), catching
regressions and filing them. Usually it takes no more than 30 minutes
per week and is a good way to learn more about Firefox internals and
interact with code you're not necessarily familiar with.

We've got detailed documentation [1] to get you started. We'll be adding
more docs about tools that make the job easier.

We've got four slots to fill ATM [2] but in the lucky case there's more
candidates than slots we're happy to rotate. Please contact me if you're
interested.

 Gabriele

[1] https://wiki.mozilla.org/NightlyCrashTriage
[2] https://wiki.mozilla.org/NightlyCrashTriage#Roster



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fission meetings at the Berlin All Hands

[Chris Peterson]

The Fission team will be hosting a few meetings at the Berlin All Hands 
to help Firefox frontend and Gecko engineers convert their code to 
Fission's async APIs.


Step 1: attend the "Introduction to Fission Engineering" presentation to 
get an overview and code examples of Fission:


* Sched: 
https://berlinallhandsjanuary2020.sched.com/event/ZDq3/introduction-to-fission-engineering


* Agenda: 
https://docs.google.com/document/d/10OWQJ-fEb1-sjAXlzBpc8EZloX8lDYFclNTvLaEiHcU/edit


Step 2: drop by the Fission team's office hours for Q or hands-on 
help! Office hours' times and locations:


* Thursday 10:30am - 12:00pm at InterContinental Schoenberg III

* Friday 1:00pm - 3:00pm at InterContinental Charlottenburg II

If you have questions about Fission's plans or meetings, just email me 
or ask in the #fission channel on Slack or Matrix.

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

Re: Searchfox at All-Hands: Who's interested?

[Andrew Sutherland]

Following up, there are now 2 identical Searchfox sessions scheduled 
hosted by some permutation of myself and Emilio and any other Searchfox 
experts who show up!  If you are interested, hopefully you can attend 
part of one of the sessions.  It's okay to show up late, the goal is to 
help people get more involved in Searchfox, not lecture you about it, so 
you won't be missing much if you're late[1].  You also don't have to 
stay for the whole time!


- Thursday: 4pm-6pm: 
https://berlinallhandsjanuary2020.sched.com/event/ZWHz/searchfox-session-1-learncontributediscuss
- Friday: 10:30am-12pm: 
https://berlinallhandsjanuary2020.sched.com/event/ZDRs/searchfox-session-2-learncontributediscuss


All subsequent coordination will be happening in #searchfox-berlin-2020 
on https://chat.mozilla.org/  which I think is 
#searchfox-berlin-2020:mozilla.org canonically.  (Note that previously I 
had mentioned an identically named channel on Slack.  We'll simulcast 
any important announcements there too, but I'd suggest bailing on the 
Slack room in favor of the Matrix room.)


Andrew

1: I will prepare a small slide deck to provide a quick overview of 
things which I'll make available by Thursday morning which should help 
you come up to speed pre-emptively or just-in-time if you miss the 
not-a-lecture at the beginning of the session.



On 1/9/20 1:43 PM, Andrew Sutherland wrote:
Are people interested in a session(s) at the All-Hands on Searchfox? 
If you're interested in any of the following things, please email me 
here or at as...@mozilla.com or let me know via other channels, and 
let me know which of the following you'd be interested in.  My goal is 
to get a rough count so I can try and book a room if there's interest.



1. Contributing to Searchfox.  Want to improve something about 
Searchfox?  You can!


We can help you get set up with a local VM and credentials to try your 
changes on mozilla-central in the cloud without your laptop melting 
down!  Already tried contributing and tried to melt your own laptop 
down out of frustration with setting up VirtualBox?  We can help with 
that too!  (Also, you can now use libvirt and save yourself a bundle 
in new laptops!)


Already have the VM setup and appreciate the extensive Searchfox 
documentation at https://github.com/mozsearch/mozsearch/ and 
https://github.com/mozsearch/mozsearch-mozilla/ but want some guidance 
on how to implement the thing you want to do?  We can help with that 
double too!



2. Talking Searchfox UX, especially as it relates to upcoming 
features/possibilities on the "fancy" branch.


I've been doing some hacking to support a more structured 
representation of data to support creating diagrams[1] for both 
documentation purposes and to make code exploration and understanding 
easier.


This potentially opens up a bunch of new features like 
https://clicky.visophyte.org/files/screenshots/20190820-174954.png 
demonstrates, providing both the type of a thing you've clicked on, 
plus being able to see its documentation or uses without having to 
click through.  But the more features you try and cram into something, 
the more potential for them to get in the way of what the user 
actually wanted to do.  For example, the helpful popup also probably 
hides the code you were trying to look at. Should the information be 
in a big box at the bottom of the screen like cs.chromium.org?  The 
top?  Configurable?


Also, for the diagrams, how to make them most accessible.  My current 
approach[2] attempts to leverage the inherent hierarchy into a ul/li 
tree-structure that directly mirrors the clustering used in the 
graphviz diagram, with in and out edges indicated at each node.  
Planned work includes figuring out how to best get NVDA to make those 
edges traversable so that the traversal is possible with more than 
manually using ctrl-f.



3. Talking Searchfox data exposure for your own tools, especially as 
it relates to the new data available on the "fancy" branch.


Do you have a tool that uses Searchfox and wish its result format 
wasn't clearly just a data structure pre-baked for presentation 
purposes that the receiving JS perform a light HTML-ization on?



Andrew


1: Here are some examples of diagrams created during prototyping:

- Manually creation by clicking on calls/called-by edges in iterative 
search results exploration: 
https://clicky.visophyte.org/files/screenshots/20190503-133733.png
- Automatic diagram from heuristics based on local same-file control 
flow: https://clicky.visophyte.org/files/screenshots/20190821-165907.png
- Blockly based diagramming without rank overrides or colors applied: 
https://clicky.visophyte.org/files/screenshots/20191231-214320.png


2: 
https://github.com/asutherland/mozsearch/blob/00a60f899936559ed4d158999278660eb5c98df5/ui/src/grokysis/frontend/diagramming/class_diagram.js#L480


___
firefox-dev mailing list
firefox-...@mozilla.org

Re: Intent to ship: Optional Chaining Operator

[Johann Hofmann]

Just a note: Please be conservative about using this in m-c while it's not
enabled in release yet, to avoid issues when uplifting patches. Otherwise,
I think this is a great new feature that I'd love to use.

On Wed, Jan 22, 2020 at 4:30 PM Patrick Brosset 
wrote:

> Thanks Yulia, this is going to be very useful and helpful in reducing code
> complexity!
>
> For info, here's a DevTools bug to make sure the console panel still
> supports autocompletion even when ?. is used:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1594009
> I also a question: do you know if eslint is ready for this new syntax? In
> other words, can we use it in m-c without causing eslint parsing errors?
>
> On Tue, Jan 21, 2020 at 8:11 PM Yulia Startsev  wrote:
>
> > Hi,
> >
> > In Firefox 74, we'll ship the optional chaining operator.
> >
> > *Bug: *https://bugzilla.mozilla.org/show_bug.cgi?id=1566143
> > *Standard: *https://tc39.es/proposal-optional-chaining/
> > *Platform coverage: *All, no pref
> > *DevTools bug: *N/A.
> > *Other browsers:* Shipping in Chrome, Shipping in Safari
> > *Testing: *
> >
> >
> https://github.com/tc39/test262/tree/master/test/language/expressions/optional-chaining
> > <
> >
> https://github.com/tc39/test262/tree/master/test/language/expressions/coalesce
> > >
> >
> > *Use cases: *Optional chaining may be useful in cases where a property
> may
> > be conditionally present. This affects property access, dynamic property
> > access, and function calls in the following way:
> >
> > *Property access*
> >
> > Before
> > const street = user.address && user.address.street;
> >
> > After
> > const street = user.address?.street;
> >
> > *Dynamic Property Access*
> > Before
> > const street = user.address && user.address["street"];
> >
> > After
> > const street = user.address?.["street"];
> >
> > *Optional function calls:*
> >
> > Before
> > const result = myObj.method && myObj.method();
> >
> > After
> > const result = myObj?.method();
> >
> >
> > *Secure contexts:* This is a JS language feature and is therefore present
> > in all contexts.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Optional Chaining Operator

[Yulia Startsev]

On Wednesday, January 22, 2020 at 4:30:33 PM UTC+1, Patrick Brosset wrote:
> Thanks Yulia, this is going to be very useful and helpful in reducing code
> complexity!
> 
> For info, here's a DevTools bug to make sure the console panel still
> supports autocompletion even when ?. is used:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1594009
> I also a question: do you know if eslint is ready for this new syntax? In
> other words, can we use it in m-c without causing eslint parsing errors?
> 
> On Tue, Jan 21, 2020 at 8:11 PM Yulia Startsev  wrote:
> 
> > Hi,
> >
> > In Firefox 74, we'll ship the optional chaining operator.
> >
> > *Bug: *https://bugzilla.mozilla.org/show_bug.cgi?id=1566143
> > *Standard: *https://tc39.es/proposal-optional-chaining/
> > *Platform coverage: *All, no pref
> > *DevTools bug: *N/A.
> > *Other browsers:* Shipping in Chrome, Shipping in Safari
> > *Testing: *
> >
> > https://github.com/tc39/test262/tree/master/test/language/expressions/optional-chaining
> > <
> > https://github.com/tc39/test262/tree/master/test/language/expressions/coalesce
> > >
> >
> > *Use cases: *Optional chaining may be useful in cases where a property may
> > be conditionally present. This affects property access, dynamic property
> > access, and function calls in the following way:
> >
> > *Property access*
> >
> > Before
> > const street = user.address && user.address.street;
> >
> > After
> > const street = user.address?.street;
> >
> > *Dynamic Property Access*
> > Before
> > const street = user.address && user.address["street"];
> >
> > After
> > const street = user.address?.["street"];
> >
> > *Optional function calls:*
> >
> > Before
> > const result = myObj.method && myObj.method();
> >
> > After
> > const result = myObj?.method();
> >
> >
> > *Secure contexts:* This is a JS language feature and is therefore present
> > in all contexts.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

Hi Patrick,

It is not available yet. The linters do not implement until stage 4. Here is 
the bug so far: https://github.com/eslint/eslint/issues/12642

There may be plugins that already support it though. If you want to use it in 
M-C you may need to update the eslint configuration depending on if you use 
babel.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Optional Chaining Operator

[Mark Banner]

ESLint doesn't implement new features until they are stage 4, so it
tends to lag behind a bit. Hence at the moment, you won't be able to use
these in our code.

ESLint's tracking issue is here
, and it looks like
they've started working on it, so hopefully it'll be implemented soon.

Mark.

On 22/01/2020 15:34, Johann Hofmann wrote:
> Just a note: Please be conservative about using this in m-c while it's
> not enabled in release yet, to avoid issues when uplifting patches.
> Otherwise, I think this is a great new feature that I'd love to use.
>
> On Wed, Jan 22, 2020 at 4:30 PM Patrick Brosset  > wrote:
>
> Thanks Yulia, this is going to be very useful and helpful in
> reducing code
> complexity!
>
> For info, here's a DevTools bug to make sure the console panel still
> supports autocompletion even when ?. is used:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1594009
> I also a question: do you know if eslint is ready for this new
> syntax? In
> other words, can we use it in m-c without causing eslint parsing
> errors?
>
> On Tue, Jan 21, 2020 at 8:11 PM Yulia Startsev  > wrote:
>
> > Hi,
> >
> > In Firefox 74, we'll ship the optional chaining operator.
> >
> > *Bug: *https://bugzilla.mozilla.org/show_bug.cgi?id=1566143
> > *Standard: *https://tc39.es/proposal-optional-chaining/
> > *Platform coverage: *All, no pref
> > *DevTools bug: *N/A.
> > *Other browsers:* Shipping in Chrome, Shipping in Safari
> > *Testing: *
> >
> >
> 
> https://github.com/tc39/test262/tree/master/test/language/expressions/optional-chaining
> > <
> >
> 
> https://github.com/tc39/test262/tree/master/test/language/expressions/coalesce
> > >
> >
> > *Use cases: *Optional chaining may be useful in cases where a
> property may
> > be conditionally present. This affects property access, dynamic
> property
> > access, and function calls in the following way:
> >
> > *Property access*
> >
> > Before
> > const street = user.address && user.address.street;
> >
> > After
> > const street = user.address?.street;
> >
> > *Dynamic Property Access*
> > Before
> > const street = user.address && user.address["street"];
> >
> > After
> > const street = user.address?.["street"];
> >
> > *Optional function calls:*
> >
> > Before
> > const result = myObj.method && myObj.method();
> >
> > After
> > const result = myObj?.method();
> >
> >
> > *Secure contexts:* This is a JS language feature and is
> therefore present
> > in all contexts.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> 
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org 
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform