Re: Improvement to build times through cleanup of C++ include dependencies

[Botond Ballo]

Hey Simon,

Thanks a lot for working on this! It's hard to notice the effect of
individual changes in this area, but in aggregate they can add up to a
significant build speed improvement.

Botond

On Mon, Dec 14, 2020 at 6:23 AM Simon Giesecke  wrote:
>
>  tl;dr Build times on all platforms, in particular for incremental builds,
> have decreased in the last weeks by landing several cleanups to C++ include
> dependencies that reduce the aggregated number of included files by about
> 30%.
>
> Hi,
>
> Did you notice a reduction in build times lately? This might not be a
> coincidence. In this mail, I want to provide some details on the
> improvements made. I want to thank everyone who contributed to this through
> up-front discussions and reviews.
>
> Recently I landed a number of patches on Bug 1676346 [1] that in various
> ways clean up C++ include directives in our codebase. Some landed ca. 3
> weeks ago, some landed last week. Overall, these reduce the aggregated
> number of included non-system header files in a full build by about 30% on
> Linux. I don't have numbers for other platforms, but they should benefit as
> well. On my machine, this reduced the time for a clobber build by about
> 10%. While that might go unnoticed, incremental builds are often sped up
> even a lot more, since the number of translation units that need to be
> rebuilt decreases. E.g. the number of translation units that include
> dom/base/Document.h reduced by ca. 52%, resulting in a build time reduction
> of 48% on my machine after modifying that. Your mileage may vary.
>
> While this might not spare you from buying new hardware, it will make
> builds faster regardless of the hardware you are running on, and hopefully
> increase productivity. If you want to share your experiences with me,
> please get in touch!
>
> You might be curious what I did to achieve that, or how you can contribute
> to reducing build times yourself. It's a combination of things, most
> importantly three things:
> 1. Remove unused include directives
> 2. Split some headers
> 3. Use forward declarations more
> 4. Hide definitions to allow using forward declarations even more
>
> About 1: I found there are several include directives that are not needed
> at all. They could simply be removed. However, the majority of cases were a
> bit more complex, because of a lot of missing include directives. When
> removing an include for X.h from a header file Y.h that doesn't need it,
> another file that included Y.h might need X.h. Or, Y.h itself might need
> something from a header indirectly included from X.h. Or similar cases.
> This meant quite a lot of more include directives for more basic things
> needed to be added to ensure the build doesn't break.
>
> About 2: Some headers have a lot of dependencies, but only relatively few
> users of that header need them. One example was IPCMessageUtils.h, which is
> included by all files generated by IPDL, which also contained a lot of
> specializations of the ParamTraits template that are needed only by few
> files. Apart from some very basic specializations, these were moved to the
> new EnumSerializers.h and IPCMessageUtilsSpecializations.h as well as some
> existing headers, so that the remaining IPCMessageUtils.h header has only
> much more limited dependencies.
>
> About 3: Our coding style favors forward declarations over inclusion of the
> full definition of types where possible. I replaced the inclusion of header
> files containing full definitions of types by forward declarations at a
> number of places where this is sufficient, e.g. because they are only used
> in function signatures. It's worth noting that there were also a number of
> cases where a forward declaration was present, but actually the full
> definition is required, e.g. when a type is used as a base class or as the
> value type of a data member, or an inline function body dereferences into a
> member.
>
> About 4: As mentioned in the last point, inline function bodies often
> require the inclusion of additional headers because they dereference into
> types of which otherwise only forward declarations were necessary. Similar
> considerations apply to private (nested) classes. Some of those were moved
> to the corresponding implementation files to hide these dependencies, and
> reduce the number of necessary includes in the header files.
>
> I was using some tools to support this, notably ClangBuildAnalyzer [2] and
> include-what-you-use [3]. ClangBuildAnalyzer helped to detect headers that
> are expensive to parse throughout the build, and direct efforts to reduce
> those specifically. But there remains a long tail of similar things that
> can and should be fixed. include-what-you-use helps to identify the headers
> from which a file uses declarations to avoid depending on indirectly
> included files which might disappear from the include chain by unrelated
> changes. These tools are not readymade for everyday use, but I will try to
> provide 

Re: Software Fallback for Web Render Dog Fooding Phase

[Botond Ballo]

On Tue, Oct 27, 2020 at 4:20 PM Jim Mathies  wrote:
> To switch to using software fallback, flip the following prefs -
>
> gfx.webrender.all = true
> gfx.webrender.software = true

Are there plans to make the second pref show up in about:config? In
today's nightly, it looks like it needs to be added manually.

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

Re: Visual Studio Code integration with `clangd` for C/C++ development

[Botond Ballo]

On Wed, Sep 16, 2020 at 3:00 AM Andi-Bogdan Postelnicu 
wrote:

> On 16 Sep 2020, at 04:14, Botond Ballo  wrote:
>
> On Tue, Sep 15, 2020 at 6:55 PM Jean-Yves Avenard 
> wrote:
>
>> This broke several features for me (and I use VSCode all the time). One in
>> particular was the inability to switch between code and header (Ctrl-K
>> Ctrl-O).
>>
>
> clangd supports this, but it's under a custom command name (as it's not
> part of the Language Server Protocol).
>
> Thank you for adding this, maybe we should also add to our documentation?
>

Good idea. I posted a documentation patch at
https://bugzilla.mozilla.org/show_bug.cgi?id=1665499.

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

Re: Visual Studio Code integration with `clangd` for C/C++ development

[Botond Ballo]

On Tue, Sep 15, 2020 at 6:55 PM Jean-Yves Avenard 
wrote:

> This broke several features for me (and I use VSCode all the time). One in
> particular was the inability to switch between code and header (Ctrl-K
> Ctrl-O).
>

clangd supports this, but it's under a custom command name (as it's not
part of the Language Server Protocol).

If you go to Keyboard Shortcuts, and search for the command
"clangd.switchheadersource", you can bind your preferred shortcut to it.


> Finding symbol definition broke under many cases too.
>

This is one we'd have to examine on a case-by-case basis. Some of them may
be upstream issues in clangd, but some may be issues in our setup (e.g.
related to unified builds).

Andi, do you have a suggestion for how to track these? Should we encourage
people to file Bugzilla tickets for them, which we can then triage (and if
appropriate, we can file upstream clangd issues)?

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

Re: Visual Studio Code integration with `clangd` for C/C++ development

[Botond Ballo]

Thanks a lot for your work on this, Andi, this is really neat!

One question:

On Thu, Sep 10, 2020 at 12:20 PM Andi-Bogdan Postelnicu 
wrote:

> VSCode  is a multi-platform
> open-source programming editor developed by Microsoft and volunteers. It is
> partly built using source-code components but also uses proprietary
> Microsoft code. It has support for many programming languages using
> extensions.
>

As far as I can tell, VSCode itself (without extensions) is FOSS, and all
the extensions listed in our extensions.json are too. The Microsoft C/C++
extension is not, but now that we have clangd we don't need that any more
(and it's no longer listed in extensions.json). Is there any remaining
"proprietary Microsoft code" in our setup that I'm overlooking?

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

Re: "static inline" in a header file is stupid, right?

[Botond Ballo]

On Fri, Jul 31, 2020 at 9:00 PM  wrote:

> Stupid: It is not stupid, it is a feature.
>

Ah, you mean `static inline` has uses in C++17 that it didn't have in older
versions?

I would appreciate an example (or a link to post etc.) so we can understand
this better.

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

Re: "static inline" in a header file is stupid, right?

[Botond Ballo]

>
> Hi! I come from the future, it is not in C++17.
>

Can you elaborate on what "it" is?

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

Dogfooding desktop zooming

[Botond Ballo]

Hi everyone!

The Firefox Graphics team has been working on *desktop zooming*, a feature
that brings the smooth pinch-zoom experience that has long been enjoyed by
mobile users, to desktop devices with touchscreens and (some) touchpads.

This is a frequently requested feature that fills an important parity gap
with other browsers and makes Firefox feel more like a first-class browser
experience on touch devices.

We believe the feature is now in a state where users on the Nightly channel
who would like to try it out can do so without major usability issues.

The feature can be enabled by setting the pref *apz.allow_zooming=true* in
about:config.

If you have a system with one of the following input devices:

   - Touchscreen (Windows or Linux)
   - Mac touchpad

then flipping this pref will allow you to perform smooth pinch-zooming on
your touchscreen or touchpad.

If you have a *Windows* device with a *precision touchpad*, you can also
perform smooth pinch-zooming on your touchpad by additionally setting
*apz.windows.use_direct_manipulation=true* in about:config.

Support for precision touchpads on Linux is planned but not yet implemented.

Even if you do not have any of these input devices, running with
apz.allow_zooming=true can still help us catch regressions in normal
browsing workflows that may involve code paths enabled by this pref.

If you encounter any issues while using this feature, please file a bug
blocking bug 1620055
 (alias
'desktop-zoom-nightly'). Please note that there are some known issues
currently blocking that bug. UX-related feedback is welcome as well, either
via a bug or in this thread.

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

Re: Faster compilers available in bootstrap

[Botond Ballo]

Thanks, compile time improvements are always good news!

Out of curiosity, does this impact builds targeting Android on Linux or Windows?

Thanks,
Botond

On Thu, Apr 9, 2020 at 12:52 PM David Major  wrote:
>
> As of bug 1326486, our clang toolchains for Linux and Windows are built
> with PGO. (Apologies to Mac users: that toolchain is cross-compiled.)
>
> Under optimal conditions (Spidermonkey build, touch mfbt) I've seen 10-15%
> compile time improvements locally, but in more common scenarios the gains
> will be diluted by other parts of the system. Perfherder measured 5-9%
> improvements in CI.
>
> To pick up a new compiler: after the next time you update your tree, run
> `./mach bootstrap` or `cd ~/.mozbuild && /path/to/mach artifact toolchain
> --from-build linux64-clang`, or on Windows replace the last part with
> `win64-clang-cl`.
>
> Happy compiling!
> ___
> 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: Upcoming C++ standards meeting in Prague

[Botond Ballo]

My blog post about the Prague C++ standards meeting is now live:
https://botondballo.wordpress.com/2020/03/12/trip-report-c-standards-meeting-in-prague-february-2020/
It can also be found on Planet Mozilla.

Cheers,
Botond


On Tue, Jan 28, 2020 at 5:03 AM Botond Ballo  wrote:
>
> 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

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

Re: Visibility of disabled tests

[Botond Ballo]

On Sat, Jan 11, 2020 at 10:38 AM James Graham  wrote:
> So in addition to the specific changes for intermittent handling, can we
> document how one nominates a bug for retriage in general (or point me at
> those docs if they already exist)

My understanding is that clearing the "priority" field is a way to
nominate a bug for retriage, since triage dashboards like [1] use the
presence of a specified priority as an indication that a bug has been
triaged.

Cheers,
Botond

[1] https://mozilla.github.io/triage-center/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visibility of disabled tests

[Botond Ballo]

On Sat, Jan 11, 2020 at 10:38 AM Geoffrey Brown  wrote:
> It might be helpful if we explicitly consider some special cases. If the
> sheriffs have needinfo'd for "needswork" and that needinfo has been
> cleared, do we  want to set needinfo again when disabling? Always? If the
> triage owner has a huge needinfo queue, still needinfo? ...

The test's author, if still active on the project, may be a good
alternative person to needinfo.

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

Re: How to generate compatible firefox for all versions of linux system?

[Botond Ballo]

According to this page [1], the current minimum version of gcc
required to build Firefox trunk is 7.1.

If you need to build with gcc 5.4, you may need to build an older
release or esr branch rather than current trunk. I don't know if the
compiler requirements are documented on a per release basis anywhere,
but searching dev-platform should allow you to get an idea of when the
minimum required version was bumped.

Cheers,
Botond

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code

On Thu, Dec 12, 2019 at 8:36 AM  wrote:
>
> Hi all,
>
> I had built a firefox on ubuntu 16.04 with GCC 5.4.0 and Glibc 2.23  from 
> Mozilla-central. Exported the package using "./mach package".
>
> firefox version 72.0a1.en
>
> When  I try to launch the  exported firefox from another ubuntu machine with 
> same config   ubuntu 16.04, GCC 5.4.0 I was getting  an error
>
>
> """
> XPCOMGlueLoad error for file /home/test/Documents/firefox/libxul.so:
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found 
> (required by /home/test/Documents/firefox/libxul.so)
> Couldn't load XPCOM
> """
>
> This requires me to upgrade GCC in that machine in order to launch the 
> browser without errors.
>
> I tried Firefox Nightly from Mozilla official releases works fine without 
> depending on the Glibc version.
>
>
> What should I do to configure and build to make the exported firefox work on 
> other machines without upgrading the GCC version?
> ___
> 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: Upcoming C++ standards meeting in Belfast

[Botond Ballo]

My blog post about this standards meeting is now live:
https://botondballo.wordpress.com/2019/11/15/trip-report-c-standards-meeting-in-belfast-november-2019/.
It can also be found on Planet Mozilla.

Cheers,
Botond

On Tue, Oct 22, 2019 at 5:13 PM Botond Ballo  wrote:
>
> Hi everyone!
>
> The next meeting of the C++ Standards Committee (WG21) will be
> November 4-9 in Belfast, Northern Ireland.
>
> This meeting will be focused on bug fixing and stabilization for
> C++20, which has achieved feature-complete status at the last meeting.
> The C++20 draft contains a number of significant new features,
> including Concepts, Modules, Coroutines, Ranges, and default
> comparisons (Contracts has slipped to C++23), so undoubtedly there
> will integration and stabilization work to be done. In parallel, the
> Evolution groups will start looking at C++23 material. A proposal for
> the committee's high-level direction for C++23 can be found here [1];
> some significant items there include contracts, networking,
> reflection, and pattern matching. I'd also like to call particular
> attention to the web_view proposal that is the subject of another
> dev-platform thread [2].
>
> 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 [3]), and the list of proposals being
> considered by the committee (new ones since the last meeting can be
> found here [4] and here [5]).
>
> I will be attending this meeting, splitting my time between the
> Evolution Working Group Incubator (which I've been roped into chairing
> at this meeting), and the Evolution Working Group itself (on days when
> the Incubator isn't running), perhaps also visiting the Reflection
> Study Group if time permits. As always, if there's anything you'd like
> me to find out for you at the meeting, or any feedback you'd like me
> to communicate, please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
> [1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0592r3.html
> [2] 
> https://groups.google.com/d/msg/mozilla.dev.platform/HGjLpdUaLsI/qxjSXwqrAAAJ
> [3] 
> https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-2019/
> [4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/#mailing2019-08
> [5] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/#mailing2019-10
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ standards proposal for a embedding library

[Botond Ballo]

On Wed, Oct 23, 2019 at 8:34 AM Henri Sivonen  wrote:
> I'm curious how developers of libstdc++ and libc++ view the notion of
> WebKitGTK+ as a platform capability. The C++ standard libraries are
> arguably for Linux while the "platform capability" named (WebKitGTK+)
> is arguably a Gnome thing rather than a Linux-level thing.

I spoke to a libstdc++ maintainer at the recent C++ standards meeting
in Belfast, and he indicated to me that he would be fine with adding
an optional dependency on WebKitGTK+, as long as he didn't have to
bundle it part of libstdc++, but could link to the platform's copy (if
present) instead.

I spoke to a libc++ maintainer as well, who indicated that there may
be engineering challenges related to scenarios where applications end
up linking to both libstdc++ and libc++. However, this is an issue
that affects all external C++ dependencies, and will need to be solved
going forward regardless of what happens to web_view.

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

Re: Passing UniquePtr by value is more expensive than by rref

[Botond Ballo]

Note that, later in his talk [1], Chandler clarifies that he still
recommends passing unique_ptr by value, because while compilers may
currently generate better code for passing them by reference, passing
them by value is still more optimizable in the long term (since
passing them by reference encodes a double indirection -- you're
passing a reference to a pointer -- in the type system).

Cheers,
Botond

[1] https://youtu.be/rHIkrotSwcc?t=2418

On Mon, Oct 14, 2019 at 8:43 AM Nathan Froyd  wrote:
>
> On Mon, Oct 14, 2019 at 3:58 AM Henri Sivonen  wrote:
> > On Mon, Oct 14, 2019 at 9:05 AM Gerald Squelart  
> > wrote:
> > >
> > > I'm in the middle of watching Chandler Carruth's CppCon talk "There Are 
> > > No Zero-Cost Abstractions" and there's this interesting insight:
> > > https://youtu.be/rHIkrotSwcc?t=1041
> > >
> > > The spoiler is already in the title (sorry!), which is that passing 
> > > std::unique_ptr by value is more expensive than passing it by rvalue 
> > > reference, even with no exceptions!
> > >
> > > I wrote the same example using our own mozilla::UniquePtr, and got the 
> > > same result: https://godbolt.org/z/-FVMcV (by-value on the left, by-rref 
> > > on the right.)
> > > So I certainly need to recalibrate my gutfeelometer.
> >
> > The discussion in the talk about what is needed to fix this strongly
> > suggested (without uttering "Rust") that Rust might be getting this
> > right. With panic=abort, Rust gets this right (
> > https://rust.godbolt.org/z/SZQaAS ) which really makes one appreciate
> > both Rust-style move semantics and the explicitly not-committal ABI.
>
> With a little voodoo placement of [[clang::trivial_abi]]
> (https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/,
> https://reviews.llvm.org/D41039) on Pair specializations and UniquePtr
> itself, one can make the by-value function look more like what you
> might expect, but at the cost (!) of making the rvalue-ref function
> look more like the original by-value function,
> https://godbolt.org/z/A1wjl8.  I think that's a reasonable tradeoff to
> make if we wanted to start using [[clang::trivial_abi]].
>
> -Nathan
> ___
> 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: C++ standards proposal for a embedding library

[Botond Ballo]

> My understanding (which may be wrong!)
> is that the purpose of the C++ proposal isn't to enable creating Web
> browsers around the API but to use the API to render the GUI for a
> local C++ app whose primary purpose isn't to browse the Web, so I
> assume "I want a URL bar" is the opposite of what the proposal is
> after.

Correct. The goal is to leverage the web platform to write C++
applications with graphical output and user interaction, not to write
browsers.

If we would find it reassuring if the proposal explicitly called out
writing browsers on top of this API as a non-goal, I can suggest that.

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

Upcoming C++ standards meeting in Belfast

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee (WG21) will be
November 4-9 in Belfast, Northern Ireland.

This meeting will be focused on bug fixing and stabilization for
C++20, which has achieved feature-complete status at the last meeting.
The C++20 draft contains a number of significant new features,
including Concepts, Modules, Coroutines, Ranges, and default
comparisons (Contracts has slipped to C++23), so undoubtedly there
will integration and stabilization work to be done. In parallel, the
Evolution groups will start looking at C++23 material. A proposal for
the committee's high-level direction for C++23 can be found here [1];
some significant items there include contracts, networking,
reflection, and pattern matching. I'd also like to call particular
attention to the web_view proposal that is the subject of another
dev-platform thread [2].

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 [3]), and the list of proposals being
considered by the committee (new ones since the last meeting can be
found here [4] and here [5]).

I will be attending this meeting, splitting my time between the
Evolution Working Group Incubator (which I've been roped into chairing
at this meeting), and the Evolution Working Group itself (on days when
the Incubator isn't running), perhaps also visiting the Reflection
Study Group if time permits. As always, if there's anything you'd like
me to find out for you at the meeting, or any feedback you'd like me
to communicate, please let me know!

Finally, I encourage you to reach out to me if you're thinking of
submitting a proposal to the committee. I'm always happy to help with
formulating and, if necessary, presenting a proposal.

Cheers,
Botond

[1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0592r3.html
[2] 
https://groups.google.com/d/msg/mozilla.dev.platform/HGjLpdUaLsI/qxjSXwqrAAAJ
[3] 
https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-2019/
[4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/#mailing2019-08
[5] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/#mailing2019-10
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ standards proposal for a embedding library

[Botond Ballo]

Hi folks,

I wanted to give an update on the "web_view" C++ standard library proposal.

I have relayed the feedback received on this thread on multiple
occasions, and our concerns about this proposal as a browser
implementer have been noted by the committee. However, the proposal
has been received positively by other participants of the committee,
including other browser vendors, and is continuing to be developed and
reviewed. While it's still at an early stage (still in front of the
Library Evolution Incubator group), it is being actively developed and
the proposed API is becoming more fleshed out.

Given that, would anyone be interested in reviewing the proposed API
and providing feedback on its design? I feel like the committee would
be receptive to constructive technical feedback, and as a group with
experience in developing embedding APIs, we are in a particularly good
position to provide such feedback.

The latest draft of the proposal can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1108r4.html

Thanks!
Botond

On Wed, Jul 18, 2018 at 12:45 PM Botond Ballo  wrote:
>
> Hi everyone,
>
> With the proposal for a standard 2D graphics library now on ice [1],
> members of the C++ standards committee have been investigating
> alternative ways of giving C++ programmers a standard way to write
> graphical and interactive applications, in a way that leverages
> existing standards and imposes a lower workload on the committee.
>
> A recent proposal along these lines is for a standard embedding
> facility called "web_view", inspired by existing embedding APIs like
> Android's WebView:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html
>
> 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 welcome.
>
> Thanks!
> Botond
>
> [1] 
> https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[Botond Ballo]

Emilio, thanks for all your work on this!

On Fri, Sep 27, 2019 at 8:23 AM Emilio Cobos Álvarez  wrote:
> Does anyone have strong opinions against removing scroll anchoring from
> Gecko, based on the above?

My 2c: it would be unfortunate to give up on scroll anchoring as a
feature altogether.

However, if we need to disable it for now, until its spec is in better
shape, I can understand that; especially as the code would
(presumably) still be there and users for whom it works well and
really want it can turn it back on by flipping the pref.

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

Re: Intent to remove: Fennec

[Botond Ballo]

On Tue, Sep 24, 2019 at 1:10 PM  wrote:
> - I have a _bunch_ of addons installed in Fennec.  uBlock Origin is by far 
> the most critical, but I have a number of other quality-of-life addons as 
> well.  Based on the articles I've seen, Fenix does not yet have any extension 
> support, so I can't even justify trying it out.

Note that this "intent to remove" email refers only to removing Fennec
code from our mainline development branch. It does not mean stopping
to ship Fennec right away. Fennec continues to be shipped from our ESR
68 branch, and will continue to do so until Fenix is considered ready
to replace it. My understanding is, extension support will definitely
be part of that.

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

Re: Coding style: Naming parameters in lambda expressions

[Botond Ballo]

On Fri, Sep 6, 2019 at 9:40 AM Andrew Sutherland
 wrote:
> But of course, if this was all being done from inside an editor or a
> debugger, no matter what tricks searchfox can do, they can't help you
> elsewhere.

Editors can of course do things of their own to help you on this
front. For example, Eclipse CDT has semantic highlighting and can
highlight parameters differently from local variables. The C++
language server clangd (which is designed to be able to plug into any
editor) recently acquired this ability as well.

I'm not saying this is a reason to retire the 'aFoo' convention (I'd
wait until technologies like the above are a bit more ubiquitous
before doing that), just mentioning the above tools because I've found
them very useful for editing Mozilla C++ code.

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

Re: Upcoming C++ standards meeting in Cologne

[Botond Ballo]

On Tue, Jul 30, 2019 at 5:32 PM Jeff Gilbert  wrote:
> I would never have guessed that any committee would have thought the failure 
> of the graphics API proposal was that it didn't go far enough.

I think of web_view as a change of direction compared to the graphics
API proposal, rather than going further in the same direction, because
web_view does not involve the committee itself hashing out APIs, it
just leverages existing APIs standardized elsewhere.

> I should also mention that as a non-majority browser engine developer, this 
> is an existential threat to Mozilla, and in turn, the web.

Could you elaborate on why that is? Naively, I would think that this
proposal would just bring new users to the web platform (namely, users
of C++ applications which previously used other facilities for
rendering and interaction, and will now use web_view).

> What can I do to help keep things on the tracks here?

If this really is an existential threat to the web, then convincing
other browser implementers to oppose it would be a good first step. So
far, other browser implementers I've talked to seemed to be
indifferent to or supportive of this proposal.

There is a meeting planned in September for browser implementers to
discuss another C++ standardization topic (TLS support in the
Networking TS) in the Bay Area, with :ekr planning to attend from our
side. As you're in the area, you could consider attending, and taking
the opportunity to bring up this topic as well.

Papers outlining arguments against a proposal in written form are also
very helpful. I've tried my best to communicate the viewports made by
other Mozilla engineers in the previous dev-platform thread on
web_view, but a 90-second oral statement made by me to a subgroup of a
dozen people does not carry nearly as much weight as a written paper
that's in the record for every committe member for read and ruminate
on.

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

Re: Upcoming C++ standards meeting in Cologne

[Botond Ballo]

On Tue, Jul 30, 2019 at 1:05 PM Nathan Froyd  wrote:
> One grotty low-level question about the new exception proposal.  Your
> post states:
>
> "it was observed that since we need to revise the calling convention
> as part of this proposal anyways, perhaps we could take the
> opportunity to make other improvements to it as well, such as allowing
> small objects to be passed in registers, the lack of which is a pretty
> unfortunate performance problem today (certainly one we’ve run into at
> Mozilla multiple times). That seems intriguing."
>
> How is revising the calling convention a C++ standards committee
> issue?  Doesn't that properly belong to the underlying platform (CPU
> and/or OS)?

"We" was a poor word choice :) What I meant was, to support
lightweight exceptions, ABI specs (lilke Itanium) will need a revised
calling convention, so perhaps they might take the opportunity to make
other improvements at the same time.

On Tue, Jul 30, 2019 at 11:56 PM Joshua Cranmer   wrote:
> On 7/30/2019 4:40 PM, Mike Hommey wrote:
> > ... and aren't small objects already passed via registers already?
>
> I wasn't at the meeting, so I can't say for sure, but I imagine the
> issue being talked about is the fact that structs/classes need to have a
> *this parameter (most notably for non-trivial constructors and
> destructors), which precludes being able to stick them in registers when
> those kick in. Watch what happens if you return a std::tuple for
> example: https://gcc.godbolt.org/z/CfbGvq (I would love to have real
> multiple return values in C++, but std::tuple still causes stack
> allocation for the return value).

I believe that's right. The specific example that came up was
unique_ptr, which unlike a raw pointer cannot be passed in a register
today [1].

Cheers,
Botond

[1] 
https://stackoverflow.com/questions/54225864/does-passing-a-unique-ptr-by-value-have-a-performance-penalty-compared-to-a-pl
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming C++ standards meeting in Cologne

[Botond Ballo]

Hi folks!

If you're interested in some more details about what happened at last
week's meeting, my blog post about it is now available (also on
Planet):

https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-2019/

Cheers,
Botond

On Sat, Jul 13, 2019 at 12:25 AM Botond Ballo  wrote:
>
> Hi everyone!
>
> The next meeting of the C++ Standards Committee (WG21) will be July
> 15-20 in Cologne, Germany.
>
> (Apologies for not sending this announcement sooner!)
>
> This is a particularly important meeting because the committee aims to
> publish the C++20 Committee Draft, a feature-complete draft of C++20
> that will be sent out for balloting and comment from national
> standards bodies, at the end of this meeting. C++20 is probably going
> to be the language's largest release since C++11, containing an
> extensive lineup of significant new features (Concepts, Modules,
> Coroutines, Contracts, Ranges, and default comparisons (<=>), among
> others). Modules has just merged into the working draft at the last
> meeting, and continues to be under active discussion due to tooling
> impacts. Contracts are at risk of being pulled due to controversy.
> Even for uncontroversial features, technical issues that we can't fix
> in time are sometimes discovered and result in the feature being
> bumped to the next release. All in all, this is going to be a busy and
> eventful meeting.
>
> 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 [1]), and the list of proposals being
> considered by the committee (new ones since the last meeting can be
> found here [2] and here [3]).
>
> I will be attending this meeting, likely splitting my time between the
> Evolution Working Group (where new language features are discussed at
> the design level) and interesting Study Groups such as SG7
> (Reflection) and SG15 (Tooling). As always, if there's anything you'd
> like me to find out for you at the meeting, or any feedback you'd like
> me to communicate, please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
> [1] 
> https://botondballo.wordpress.com/2019/03/20/trip-report-c-standards-meeting-in-kona-february-2019/
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-03
> [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-06
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming C++ standards meeting in Cologne

[Botond Ballo]

On Thu, Jul 18, 2019 at 5:21 PM Botond Ballo  wrote:
> I'm not technically allowed to talk about the discussions that have
> taken place so far this week (and in any case nothing is final until
> the plenary votes on Saturday), but please do check /r/cpp on Saturday
> and have a look at the collaborative trip report that's usually
> released very soon after plenary ends. My strong suspicion is that one
> way or another, your fears will be allayed.

So, as described in the mentioned trip report [1], Contracts has been
pulled from C++20 and is now targeting C++23.

While the C++23 design is very much open at this stage, I have high
confidence that it will include a mechanism to make contracts have no
effect when not checked, like you want.

Cheers,
Botond

[1] 
https://www.reddit.com/r/cpp/comments/cfk9de/201907_cologne_iso_c_committee_trip_report_the/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming C++ standards meeting in Cologne

[Botond Ballo]

Hi Jason,

You're definitely not the only one with this concern! Contracts and
undefined behaviour have been a heated topic for quite some time, and
concerns like yours have motivated proposals like this one [1] to
address them.

> We could use this only if Clang adds a mode that, contrary to the standard, 
> guarantees that unchecked contracts do exactly nothing, while retaining all 
> the other optimizations that we rely on.

Having the standard allow for or even mandate such a mode, or
alternatively to avoid the need for "modes" by allowing the author to
specify the desired semantics in the code itself, is a very popular
request and the subject of several other papers, such as this one [2].

I'm not technically allowed to talk about the discussions that have
taken place so far this week (and in any case nothing is final until
the plenary votes on Saturday), but please do check /r/cpp on Saturday
and have a look at the collaborative trip report that's usually
released very soon after plenary ends. My strong suspicion is that one
way or another, your fears will be allayed.

With all that said, on the topic of blanket avoidance of undefined
behaviour, I've found this CppCon talk by Chandler Carruth [3] to be
very informative, and I would recommend it.

Cheers,
Botond

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1290r3.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1429r2.pdf
[3] https://www.youtube.com/watch?v=yG1OZ69H_-o

On Thu, Jul 18, 2019 at 11:27 AM Jason Orendorff  wrote:
>
> Botond,
>
> Presumably it's too late for the ongoing meeting, but I'm very concerned 
> about C++20 assertions.
>
> The proposal says that in a release build, any contract violation is 
> undefined behavior. Sounds reasonable enough.
>
> Every assertion adds potential UB. Hmm.
>
> ISTM this makes the feature very much off-limits for us. Undefined behavior 
> is bad. It accounts for most security vulnerabilities in Firefox. We could 
> use this only if Clang adds a mode that, contrary to the standard, guarantees 
> that unchecked contracts do exactly nothing, while retaining all the other 
> optimizations that we rely on.
>
> But is it really just us? Are these semantics good for anyone? C++20 
> assertions seem to be a software-engineering quality-assurance feature 
> crazy-glued to a very tricky, dangerous, 
> squeeze-out-the-last-few-drops-of-CPU performance feature. But those two 
> things are more useful separately; and surely the latter should not be 
> designed to look like the former. I would like to understand the motivation 
> behind this.
>
> -j
>
> On Fri, Jul 12, 2019 at 11:25 PM Botond Ballo  wrote:
>>
>> Hi everyone!
>>
>> The next meeting of the C++ Standards Committee (WG21) will be July
>> 15-20 in Cologne, Germany.
>>
>> (Apologies for not sending this announcement sooner!)
>>
>> This is a particularly important meeting because the committee aims to
>> publish the C++20 Committee Draft, a feature-complete draft of C++20
>> that will be sent out for balloting and comment from national
>> standards bodies, at the end of this meeting. C++20 is probably going
>> to be the language's largest release since C++11, containing an
>> extensive lineup of significant new features (Concepts, Modules,
>> Coroutines, Contracts, Ranges, and default comparisons (<=>), among
>> others). Modules has just merged into the working draft at the last
>> meeting, and continues to be under active discussion due to tooling
>> impacts. Contracts are at risk of being pulled due to controversy.
>> Even for uncontroversial features, technical issues that we can't fix
>> in time are sometimes discovered and result in the feature being
>> bumped to the next release. All in all, this is going to be a busy and
>> eventful meeting.
>>
>> 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 [1]), and the list of proposals being
>> considered by the committee (new ones since the last meeting can be
>> found here [2] and here [3]).
>>
>> I will be attending this meeting, likely splitting my time between the
>> Evolution Working Group (where new language features are discussed at
>> the design level) and interesting Study Groups such as SG7
>> (Reflection) and SG15 (Tooling). As always, if there's anything you'd
>> like me to find out for you at the meeting, or any feedback you'd like
>> me to communicate, please let me know!
>>
>> Finally, I encourage you to reach out to me if you're thinking of
>> submitting a proposal to the committee. I'm always happy to help with

Upcoming C++ standards meeting in Cologne

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee (WG21) will be July
15-20 in Cologne, Germany.

(Apologies for not sending this announcement sooner!)

This is a particularly important meeting because the committee aims to
publish the C++20 Committee Draft, a feature-complete draft of C++20
that will be sent out for balloting and comment from national
standards bodies, at the end of this meeting. C++20 is probably going
to be the language's largest release since C++11, containing an
extensive lineup of significant new features (Concepts, Modules,
Coroutines, Contracts, Ranges, and default comparisons (<=>), among
others). Modules has just merged into the working draft at the last
meeting, and continues to be under active discussion due to tooling
impacts. Contracts are at risk of being pulled due to controversy.
Even for uncontroversial features, technical issues that we can't fix
in time are sometimes discovered and result in the feature being
bumped to the next release. All in all, this is going to be a busy and
eventful meeting.

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 [1]), and the list of proposals being
considered by the committee (new ones since the last meeting can be
found here [2] and here [3]).

I will be attending this meeting, likely splitting my time between the
Evolution Working Group (where new language features are discussed at
the design level) and interesting Study Groups such as SG7
(Reflection) and SG15 (Tooling). As always, if there's anything you'd
like me to find out for you at the meeting, or any feedback you'd like
me to communicate, please let me know!

Finally, I encourage you to reach out to me if you're thinking of
submitting a proposal to the committee. I'm always happy to help with
formulating and, if necessary, presenting a proposal.

Cheers,
Botond

[1] 
https://botondballo.wordpress.com/2019/03/20/trip-report-c-standards-meeting-in-kona-february-2019/
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-03
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-06
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Revising the frequency threshold for disabling intermittents?

[Botond Ballo]

On Mon, Jul 8, 2019 at 1:29 PM Maher（ 馬羅成 ）Joel  wrote:
> Here you can see the pushes we have over time:
> https://sql.telemetry.mozilla.org/dashboard/firefox-ci
>
> looking at a monthly level, I see these numbers for (autoland, inbound, 
> central):
> July 2018 - 2049
> June 2019 - 2376

Ok, I guess I was misled by the numbers in the "X failures in Y
pushes" figures in the Intermittent Failures Robot comments. Perhaps
we could fix those / tweak them to be more reflective of the actual
failure rate?

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

Revising the frequency threshold for disabling intermittents?

[Botond Ballo]

Hi folks,

We have a policy of disabling intermittently failing tests is they
fail more than 150 times over 21 days [1] (revised from 200 times over
30 days [2], which was a very similar failure rate just evaluated over
a slightly longer period).

When the policy was originally put in place in September 2017, on a
typical week we'd have between 800 and 1000 pushes [3], so the policy
meant disabling tests if they fail at a rate of roughly 5% (50
failures/week out of 1000 pushes/week).

These days, on a typical week we have between 4000 and 5000 pushes
[4]. The threshold is the same, so we're now disabling tests if they
fail at a rate of roughly 1% (50 failures/week out of 5000
pushes/week).

>From an engineering point of view, keeping tests passing at a failure
rate of below 1% is a much more significant challenge than keeping
them passing at a failure rate of below 5% (since failures that are
very infrequent are very time-consuming to reproduce and iterate on).

Should we perhaps be revising our disablement threshold to keep pace
with the number of pushes per week?

Thanks,
Botond

[1] 
https://groups.google.com/d/topic/mozilla.dev.platform/346SQCu0NAM/discussion
[2] 
https://groups.google.com/d/topic/mozilla.dev.platform/uJVTekj2l7I/discussion
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1340667#c14
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1476893#c37
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

[Botond Ballo]

On Thu, Jul 4, 2019 at 2:03 PM Jeff Gilbert  wrote:
> It's a huge
> help to have a compile-time constraint that values can't be negative.

The question is, how useful is that guarantee. Suppose you have some
code that decrements an integer too far, past zero. Instead of having
a -1 you'll have a 4294967295. Is that an improvement? Will it give
the code saner behaviour than the -1?

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

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

[Botond Ballo]

On Thu, Jul 4, 2019 at 7:11 AM Henri Sivonen  wrote:
> > Do you happen to know why?  Is this due to worries about underflow or
> > odd behavior on subtraction or something?
>
> I don't _know_, but most like they want to benefit from optimizations
> based on overflow being UB.

My understanding is yes, that's one of the motivations.

Another, as hinted at in Gerald's quote, is that tools like UBSan can
diagnose and catch signed overflow because it's undefined behaviour.
They can't really do that for unsigned overflow because, since that's
defined to wrap, for all the tool knows the code author intended for
the overflow and wrapping to occur.

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

Re: Intent to ship: Visual Viewport API on Android

[Botond Ballo]

Hi,

> Target release: Firefox 68 or 69, depending on when the patches are
> ready. If it doesn't make 68, I would like to get it into Fennec
> 68.1esr, as it's an important web compat feature.

Just wanted to follow up and say that this did make 68.

There is one remaining Android wpt failure [1] which I hope to
investigate in the near future and uplift to 68 if possible.

Thanks,
Botond

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

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

[Botond Ballo]

On Wed, May 15, 2019 at 6:54 PM Jean-Yves Avenard  wrote:
> It is then up to each process to handle preference modifications and
> pass that change. There's no automatic or universal method on how this
> is done unfortunately.

Will SpecialPowers.pushPrefEnv(), which currently does propagate the
prefs at least between the content and parent processes, continue to
work? A lot of tests rely on this.

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

Re: Intent to ship: Visual Viewport API on Android

[Botond Ballo]

On Thu, May 9, 2019 at 7:50 AM David Burns  wrote:
> There are a number of wpt that fail only in firefox. Are we planning on 
> fixing those tests with this work?

We are, at least on Android. (On desktop, some of the tests need
desktop zooming, which we do not yet have, to pass.) A number of fixes
have landed [1] yesterday.

Is there a way to get a dashboard view similar to [2] with Android results?

Thanks,
Botond

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1477610
[2] 
https://jgraham.github.io/wptdash/?bugComponent=core%3A%3Alayout=%2Fvisual-viewport=Interop+Comparison
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Visual Viewport API on Android

[Botond Ballo]

Hi everyone!

I would like to ship the Visual Viewport API [1] on Android. The
initial implementation [2] was done in Firefox 63 behind the pref
"dom.visualviewport.enabled" (see "Intent to Implement" thread [3]).
It has since seen bug fixes, polish, and expanded test coverage.

I intend to ship it on Android only for now. The API is primarily
useful in scenarios involving pinch-zooming, and we don't currently
support pinch-zooming on desktop. I intend to enable it on desktop
concurrently with support for pinch-zooming at a later date.

Target release: Firefox 68 or 69, depending on when the patches are
ready. If it doesn't make 68, I would like to get it into Fennec
68.1esr, as it's an important web compat feature.

Tracking bug for shipping: https://bugzilla.mozilla.org/show_bug.cgi?id=1512813

Status in other implementation:
  Blink: Shipping since Chrome 61 [4]
  Safari: Available in Preview version [5]

Web platform tests: The feature has good WPT coverage, with a mix of
automatic and manual tests. We are now [6] passing almost all tests on
Android; of the two remaining failures, one is a test harness
limitation [7], and the other is pending resolution of a spec issue
[8]. There are also a couple of tests which are not applicable to
Android because they involve reflowing zoom which Android does not
support.

Any thoughts / feedback is appreciated!

Thanks,
Botond

[1] https://github.com/WICG/visual-viewport/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1357785
[3] 
https://groups.google.com/d/topic/mozilla.dev.platform/gchNtWfv_bk/discussion
[4] https://www.chromestatus.com/feature/5737866978131968
[5] https://webkit.org/status/#feature-visual-viewport-api
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1477610
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1547827
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1543485
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ Developer Survey "Lite"

[Botond Ballo]

> If you're a C++ developer and care about the future of the language, I
> encourage you to fill out the survey:

There's a 2019 version of the survey that folks are likewise
encouraged to fill out:

https://isocpp.org/blog/2019/04/second-annual-cpp-foundation-developer-survey-lite

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

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

[Botond Ballo]

On Thu, Apr 25, 2019 at 4:58 PM Bobby Holley  wrote:
> we won't ship Fennec past ESR68

That's news to me. Was this announced somewhere? Is there a discussion
you could point me to?

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

Re: Upcoming C++ standards meeting in Kona

[Botond Ballo]

For those interested, my blog post about this meeting is now online:

https://botondballo.wordpress.com/2019/03/20/trip-report-c-standards-meeting-in-kona-february-2019/

It's also available on Planet Mozilla.

Cheers,
Botond

On Tue, Feb 12, 2019 at 9:08 PM Botond Ballo  wrote:
>
> Hi everyone!
>
> The next meeting of the C++ Standards Committee (WG21) will be
> February 18-23 in Kona, Hawaii.
>
> The C++20 cycle is starting to wrap up, and the fate of several large
> features is likely to be decided at this meeting. Concepts and Ranges
> have merged at the last meeting, while Coroutines and Contracts are
> continuing to attract controversy. Modules has achieved fairly broad
> implementer consensus, and schedule-wise is largely on track to make
> C++20, but there are concerns about it in the tooling community [1].
> The eventual shape of Reflection (a post-C++20 feature) continues to
> be debated.
>
> 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, likely splitting my time between the
> Evolution Working Group (where new language features are discussed at
> the design level), and the EWG Incubator group (where proposals bound
> for Evolution undergo a preliminary round of feedback). As always, if
> there's anything you'd like me to find out for you at the meeting, or
> any feedback you'd like me to communicate, please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1427r0.pdf
> [2] 
> https://botondballo.wordpress.com/2018/11/30/trip-report-c-standards-meeting-in-san-diego-november-2018/
> [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#mailing2018-11
> [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-01
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Upcoming C++ standards meeting in Kona

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee (WG21) will be
February 18-23 in Kona, Hawaii.

The C++20 cycle is starting to wrap up, and the fate of several large
features is likely to be decided at this meeting. Concepts and Ranges
have merged at the last meeting, while Coroutines and Contracts are
continuing to attract controversy. Modules has achieved fairly broad
implementer consensus, and schedule-wise is largely on track to make
C++20, but there are concerns about it in the tooling community [1].
The eventual shape of Reflection (a post-C++20 feature) continues to
be debated.

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, likely splitting my time between the
Evolution Working Group (where new language features are discussed at
the design level), and the EWG Incubator group (where proposals bound
for Evolution undergo a preliminary round of feedback). As always, if
there's anything you'd like me to find out for you at the meeting, or
any feedback you'd like me to communicate, please let me know!

Finally, I encourage you to reach out to me if you're thinking of
submitting a proposal to the committee. I'm always happy to help with
formulating and, if necessary, presenting a proposal.

Cheers,
Botond

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1427r0.pdf
[2] 
https://botondballo.wordpress.com/2018/11/30/trip-report-c-standards-meeting-in-san-diego-november-2018/
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#mailing2018-11
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-01
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nasm will soon become a build dependency

[Botond Ballo]

On Fri, Dec 21, 2018 at 4:21 PM Kartikaya Gupta  wrote:
>
> On Fri, Dec 21, 2018 at 4:10 PM Thomas Daede  wrote:
> > There is a toolchain build for nasm for windows:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1511224
> >
> > If getting a newer nasm version is inconvenient for a majority of linux
> > users, the toolchain build could be used to produce nasm binaries for
> > mach bootstrap as well.
>
> I would certainly prefer this, and having this work smoothly would
> also be good for new contributors. Having to build and install extra
> packages is always a hassle.

+1

Debian stable is in this boat as well - the latest nasm version in its
package repositories is 2.12.

This is the first time, as far as I'm aware, that building Firefox
requires manually building another package - everything else is taken
care of by |mach bootstrap|.

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

Re: Upcoming changes to our C++ Coding Style

[Botond Ballo]

On Fri, Dec 7, 2018 at 11:36 AM Sylvestre Ledru  wrote:
> In the meantime, we will be running a bot weekly to reformat the
> mistakes and add the changeset into the ignore lists.
> But in the long run this won’t be sustainable, so once we gain
> confidence that a good number of developers have successfully integrated
> clang-format into their local workflow, we will look into enabling a
> Mercurial hook on hg.mozilla.org to reject misformatted code upon push
> time.  That will be the ultimate solution to help ensure that our code
> will be properly formatted at all times.

Have you considered something like running clang-format automatically
during landing (i.e. as part of what Lando does to the patch)? That
seems like it would achieve the best of both worlds, by not placing
any requirements on what developers do locally, while also ensuring
the tree is always properly formatted without cleanup commits.

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

Re: Upcoming changes to our C++ Coding Style

[Botond Ballo]

Hi,

I'd like to ask a couple of clarifications about process here:

* Is clang-format invoked automatically as part of a pre-commit hook,
or something like that?
* If not, should we be invoking it manually before submitting a patch?
* If we submit a patch without having invoked it, will violations be
caught in automation? Will they trigger a backout?

Thanks,
Botond
On Thu, Nov 22, 2018 at 12:36 PM Felipe G  wrote:
>
>  On Thu, Nov 22, 2018 at 3:07 PM Ehsan Akhgari 
> wrote:
>
> > Felipe, gps and I talked a bit about adding a similar
> > .hg-blame-ignore-revs file in the tree which can contain Mercurial sha1
> > changeset IDs for the rewrite commits to be skipped over, and people would
> > be able to use the file through an alias that can be configured in ~/.hgrc
> > (possible to set it up via ./mach bootstrap).  Not sure if Felipe's
> > investigations have lead to results yet.
> >
>
> Indeed they have. I'm working on this in two separate bugs:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1508002 is implementing the
> same functionality in mercurial from`git hyper-blame`, and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1508324 will be used to
> generate the list of past changesets
>
> Hope to have these wrapped up soon, and I'll write about them once they're
> done. One thing to mention in advance is that gps asked to not use the word
> "blame" as the Mercurial project doesn't like the negative connotations
> that it brings, so I'm leaning towards `hg smart-annotate` and "#
> ignore-changeset" for the string to be included in the commit message. Let
> me know if anyone has thoughts about these (or leave comments in the bug)
>
> Felipe
> ___
> 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: Upcoming C++ standards meeting in San Diego, California

[Botond Ballo]

Hi everyone,

My blog post about the C++ standards meeting that took place earlier
this month is now published:

https://botondballo.wordpress.com/2018/11/30/trip-report-c-standards-meeting-in-san-diego-november-2018/

Cheers,
Botond

On Mon, Oct 22, 2018 at 5:52 PM Botond Ballo  wrote:
>
> Hi everyone!
>
> The next meeting of the C++ Standards Committee will be November 5-10
> in San Diego, California.
>
> This is promising to be the Committee's largest meeting to date, both
> in terms of attendees (expected over 150), and submitted proposals
> (over 250 in the pre-meeting mailing). This is encouraging, as it
> reflects a heightened level of interest in the language and its
> standardization. At the same time, the committee is undertaking some
> procedural changes to stay afloat this sea of proposals, notably
> spinning up new Incubator subgroups to process / filter through
> proposals for new extensions before the main Evolution and Library
> Evolution groups look at them.
>
> Meanwhile, work continues on C++20, with Ranges and "natural syntax"
> Concepts on the brink of consensus, Modules making really good
> progress with the committee working extra hard to get them into C++20,
> and Coroutines continuing to be under debate with two competing
> proposals. 2D Graphics is dead for now, though it may yet rise from
> the ashes [1]. Reflection, Executors, and several other features are
> moving forward in the form of Technical Specifications.
>
> 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, likely splitting my time between
> Evolution Working Group (where new language features are discussed at
> the design level), and the EWG Incubator group (where proposals bound
> for Evolution undergo a preliminary round of feedback). As always, if
> there's anything you'd like me to find out for you at the meeting, or
> any feedback you'd like me to communicate, please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
>
> [1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1200r0.pdf
> [2] 
> https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/
> [3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/#mailing2018-06
> [4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/#mailing2018-10
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming C++ standards meeting in San Diego, California

[Botond Ballo]

On Mon, Oct 22, 2018 at 7:47 PM,   wrote:
> Here's one I'd like:
>   for (int i = ...; test(i); i = next(i)) {
> if (good_stuff(i)) { break; /* goto past `else` block */ }
>   } else {
> /* test(i) failed, i.e., we didn't `break` */
> do_something(i); // decls inside `for(...)` still in scope.
>   }
> and/or:
>   for (auto& x: xs) {
> if (good_stuff(x)) { break; /* goto past `else` block */ }
>   } else {
> /* went off-range, i.e., we didn't `break` */
>   }

This has actually been proposed before! Here's the latest iteration of
the proposal (dated February 2017):

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0082r2.pdf

and here's my summary of its discussion, from my blog post about the
meeting where it was discussed [1]:

"An updated version of for loop exit strategies, which proposes to
allow adding blocks of code at the end of a for loop that run when the
loop exits by breaking (introduced by the keyword on_break), and when
the loop runs to completion (introduced by on_complete). The only
thing that has changed since the last revision of this proposal is the
keywords – they were catch break and catch default in the previous
version. EWG didn’t love the new keywords, either, and was generally
lukewarm towards the proposal in terms of motivation, so it’s not
clear if this is going anywhere."

Given that this has already been proposed and effectively shot down, I
think it makes to try and re-propose it only if we have new
information to bring to the table, e.g. compelling new motivation or a
design alternative that hasn't been considered.

Cheers,
Botond


[1] 
https://botondballo.wordpress.com/2017/03/27/trip-report-c-standards-meeting-in-kona-february-2017/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Upcoming C++ standards meeting in San Diego, California

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee will be November 5-10
in San Diego, California.

This is promising to be the Committee's largest meeting to date, both
in terms of attendees (expected over 150), and submitted proposals
(over 250 in the pre-meeting mailing). This is encouraging, as it
reflects a heightened level of interest in the language and its
standardization. At the same time, the committee is undertaking some
procedural changes to stay afloat this sea of proposals, notably
spinning up new Incubator subgroups to process / filter through
proposals for new extensions before the main Evolution and Library
Evolution groups look at them.

Meanwhile, work continues on C++20, with Ranges and "natural syntax"
Concepts on the brink of consensus, Modules making really good
progress with the committee working extra hard to get them into C++20,
and Coroutines continuing to be under debate with two competing
proposals. 2D Graphics is dead for now, though it may yet rise from
the ashes [1]. Reflection, Executors, and several other features are
moving forward in the form of Technical Specifications.

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, likely splitting my time between
Evolution Working Group (where new language features are discussed at
the design level), and the EWG Incubator group (where proposals bound
for Evolution undergo a preliminary round of feedback). As always, if
there's anything you'd like me to find out for you at the meeting, or
any feedback you'd like me to communicate, please let me know!

Finally, I encourage you to reach out to me if you're thinking of
submitting a proposal to the committee. I'm always happy to help with
formulating and, if necessary, presenting a proposal.

Cheers,
Botond


[1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1200r0.pdf
[2] 
https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/
[3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/#mailing2018-06
[4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/#mailing2018-10
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Botond Ballo]

One potential issue here is that an assertion failure in Nightly
builds might be simultaneously very annoying (because it crashes the
browser of Nightly users every time it occurs) and not very actionable
(because no reliable STR can be found for it). That's the situation
I'm in with bug 1457603, for example, where I may have to end up
_downgrading_ a diagnostic assert that I added, to a regular assert.

On Mon, Sep 17, 2018 at 3:25 PM, Jeff Gilbert  wrote:
> I would be excited for something between MOZ_ASSERT and MOZ_CRASH, but
> I think raising MOZ_ASSERTs to MOZ_ASSERT_NIGHTLY should be done by
> hand and reviewed.
>
> On Mon, Sep 17, 2018 at 11:46 AM, Kris Maglione  wrote:
>> There are some non-trivial snags for this proposal. A lot of assertions rely
>> on other code gated on #ifdef DEBUG or DebugOnly<...> to avoid defining data
>> members or storing values in non-debug builds. We could replace those with
>> more fine-grained macros, of course, but particularly in the case of data
>> members, we'd probably also take a significant memory usage regression.
>>
>> There's also the snag of NS_ASSERTION macros which are... weird.
>>
>> This is nothing we can't deal with, of course, but it will probably require
>> a lot of manual work if we want to do it correctly.
>>
>>
>> On Mon, Sep 17, 2018 at 02:38:14PM -0400, Randell Jesup wrote:
>>>
>>> There are quite a few things that may be caught by assertions by
>>> developers before committing, especially sec issues - but most
>>> developers don't run debug builds as their main local test builds, or
>>> for local browsing use, because they are almost unusably slow.  And
>>> turning on compiler optimization doesn't actually help much here - the
>>> problem is mostly debug-only assertions and code that's debug only, such
>>> as bug 1441052 ("Don't do full grey-node checking in local debug
>>> builds").
>>>
>>> These added checks may be useful for CI tests, but they make the builds
>>> unusable, so the vast majority of assertions don't run in the builds our
>>> developers are using.  So enabling most of the existing MOZ_ASSERTs for
>>> local opt builds (minus the worst performance-limiting ones) would help
>>> developers catch bugs before landing them (and perhaps shipping
>>> them). It's a lot like using ASAN builds to browse - but with much less
>>> perf degradation on hopes.
>>>
>>> Even better, if we can make the overall hit to perf low enough (1%?), we
>>> could enable it for some/all Nightly users/builds.  Or make "early
>>> nightly" (and developer builds) enable them, and late nightly and beta
>>> not.
>>>
>>> If we moved some of the most expensive checks to an alternative macro
>>> (MOZ_ASSERT_DEBUG()), we could (selectively?) enable MOZ_ASSERT checks
>>> in some opt builds.  Alternatively we could promote some MOZ_ASSERTs to
>>> MOZ_ASSERT_NIGHTLY() (or MOZ_DIAGNOSTIC_ASSERT), which would assert in
>>> (all) debug builds, and in nightly opt builds - and maybe promote some
>>> to MOZ_ASSERT_RELEASE if we can take the perf hit, and they're in an
>>> important spot.
>>>
>>> And as a stepping-stone to the above, having local opt builds enable
>>> (most) MOZ_ASSERTs (excluding really expensive ones, like bug 1441052)
>>> even if the hit is larger (5, 10%) would also increase the likelihood
>>> that we'll catch things before we land them, or before they get to beta.
>>> (Note: --enable-release would turn this local-build behavior off - and
>>> anyone doing speed tests/profiling/etc needs that already, and probably
>>> we should have a specific enable/disable like
>>> --disable-extra-assertions).  This wouldn't be all that hard - most of
>>> the work would be finding "expensive" assertions like bug 1441052.
>>>
>>> (and perhaps we should not continue to overload --enable-release for "I
>>> want to benchmark/profile this build")
>>>
>>> Enabling most MOZ_ASSERTs in automation tests on opt builds would also
>>> slightly increase our odds of finding problems - though this may not
>>> help much, as the same tests are being run in debug builds.  The only
>>> advantage would be races may be more likely in the faster opt builds.
>>> It might be worth trying once we have this for a few weeks, and see if
>>> it helps or not.
>>>
>>> Note: I've discussed this concept with various people including bz in
>>> the past, and mostly have had agreement that this would be useful - thus
>>> my filing of bug 1441052.  If we agree this is worth doing, we should
>>> file bugs on it and see what the effort to get this would be, and if we
>>> could ship some of this to users.  Much like nightly-asan, this would
>>> shake out bugs we'll never find from crash-stats reports, and which can
>>> lead to critical sec bugs, and turn them into frequently-actionable
>>> bugs.  If needed this can be enabled incrementally once the build/config
>>> infra and macros are in place; there are several options for that.
>>
>> ___
>> dev-platform mailing list
>> 

Re: Plan for Sunsetting MozReview

[Botond Ballo]

> Until this gets fixed, a workaround for closed bugs is to go to the bottom of 
> the bug, and look for https://hg.mozilla.org/mozilla-central/rev/... links.
> Not as pretty, and missing review context, but hopefully this should help 
> explore the changed code in most cases.

For bugs that aren't closed, or where you specifically want to look at
an older revision than the one that landed, you can also query the
review repo for all revisions associated with a bug:

https://hg.mozilla.org/mozreview/gecko/log?rev=

(assuming the bug number is present in the commit message).

Hope that helps!

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

Re: ./mach try fuzzy: A Try Syntax Alternative

[Botond Ballo]

Is there an easy way to do a T-push (builds on all platforms, tests on
one platform only) with |mach try fuzzy|?

I usually do T-pushes using try syntax, by Trychooser seems to be out
of date when it comes to building a T-push syntax for Android, so I'm
at a loss as to how to do a T-push for Android right now.

Thanks,
Botond

On Wed, Aug 2, 2017 at 10:30 AM, Andrew Halberstadt
 wrote:
> I'm pleased to announce an alternative method for scheduling tasks on try
> is now landed on mozilla-central. It makes use of the awesome fzf [1]
> project to filter down the list of all task labels with a fuzzy matching
> algorithm.
>
> It works both with mercurial or git. If using mercurial, you'll need to
> make sure you're updated to the latest version-control-tools:
>
> $ ./mach mercurial-setup --update
>
> To push to try, run:
>
> $ ./mach try fuzzy
>
> This will prompt you to install fzf. After bootstrapping is complete, it'll
> generate the task list. This takes around ~10-20 seconds, but will be
> cached so subsequent invocations won't incur this penalty again.
>
> Now you'll be in the fzf interface. Basic usage is to start typing to
> filter down the task list. You can use the arrow keys to move the cursor up
> or down,  to select a task,  to select all tasks and 
> to schedule the current selection (and their dependencies) on try.
>
> There are a ton more keyboard shortcuts and features you can use to tweak
> fzf just to your liking. For extra help, see:
>
> $ ./mach try fuzzy --help
> or
> $ man fzf
>
> For a demo and more information on implementation details, see:
> https://ahal.ca/blog/2017/mach-try-fuzzy/
>
> I expect this to work on all platforms including Windows for both mercurial
> (with push-to-try) and git (with git-cinnabar). But it's a new tool without
> a lot of real world testing, so a few bumps are likely. If you find any
> bugs or bad UX, please file a bug under Testing :: General and let me know
> (we should find a better component for this).
>
> Cheers,
> Andrew
>
> p.s When running the fzf bootstrap, you'll be prompted to install some
> shell extensions. These aren't necessary for |mach try fuzzy| to work so
> feel free to hit 'N' at each prompt. That being said, the fzf shell
> extensions are awesome. I highly encourage you to look into setting it up
> for your shell. The fzf vim plugin is also great. See the project [1] for
> more details.
>
> [1] https://github.com/junegunn/fzf
> ___
> 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: Plan for Sunsetting MozReview

[Botond Ballo]

On Thu, Jul 26, 2018 at 2:37 PM, Mark Côté  wrote:
> Every landed, in-progress, and abandoned patch will be downloaded
> from MozReview and stored in an S3 bucket.

I think I've asked this before, but plans were uncertain at the time:
will the history of patches (i.e. otherwise unpublished ancestors that
are currently stored in the MozReview repo) be archived as well?

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

Re: Intent to implement: Visual Viewport API

[Botond Ballo]

On Tue, Jul 24, 2018 at 4:22 AM, Michael de Boer  wrote:
> About the desktop perspective: is pinch-to-zoom a completely separate thing 
> from full-page-zoom as can be controlled right now with Ctrl+ and Ctrl- using 
> the
> keyboard?

Yes. The two have different behaviours (as Boris mentioned, one
reflows the page, one does not).

> If that’s the case, I can see synchronization issues between the two features 
> when they’re both in use.

Could you elaborate? As far as I'm aware, other browsers like Chrome
and Safari support both at the same time on desktop.

> My perception is that pinch-to-zoom is really full-page-zoom, but using the 
> pointer coordinates as focal point instead of [0,0] and step-less zooming 
> behaviour, instead of clamping to predefined steps.

Currently, pinch gestures on a trackpad are hooked up to perform
full-page zooming on desktop. This is a temporary measure until pinch
zooming is implemented on desktop. Once pinch zooming is implemented
on desktop, pinch gestures will be hooked up to perform that.

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

Re: C++ standards proposal for a embedding library

[Botond Ballo]

On Thu, Jul 19, 2018 at 5:35 PM, Mike Hommey  wrote:
> Other than everything that has already been said in this thread,
> something bugs me with this proposal: a web view is a very UI thing.
> And I don't think there's any proposal to add more basic UI elements
> to the standard library.

Not that I'm aware of.

> So even if a web view is a desirable thing in
> the long term (and I'm not saying it is!), there are way more things
> that should come first.

I think the idea behind this proposal is that standardizing a UI
framework for C++ would be too difficult (seeing as we couldn't even
agree on a 2D graphics proposal, which is an ingredient in a UI
framework), so the web view fills the role of the UI framework: your
UI is built inside the web view. (Not saying that's a good idea or a
bad idea, just trying to explain the line of thinking.)

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

Re: C++ standards proposal for a embedding library

[Botond Ballo]

On Wed, Jul 18, 2018 at 8:04 PM, L. David Baron  wrote:
> It feels like this bakes into the C++ language the idea that a
> machine only ever needs a single implementation of the web platform.
>
> I (and I think many others at Mozilla) think that users are better
> served by competition among implementations of the Web's technology,
> since it allows competition to better serve the interests of users
> and allows more flexibility in the evolution of the platform due to
> fewer mistakes getting quickly baked in to the platform by
> compatibility.
>
> This makes me think it's a bad idea to standardize a Web View API as
> part of C++.

Is having a Web View API fundamentally incompatible with there being
multiple implementations to select from?

Suppose the API had a mechanism to query a list of available
implementations, and you could specify which one to use when
instantiating a web view - would that address this concern?

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

Re: C++ standards proposal for a embedding library

[Botond Ballo]

On Wed, Jul 18, 2018 at 5:31 PM, Boris Zbarsky  wrote:
> If the intent is that the default behavior is to speak http, what are the
> committee's thoughts on things like sandboxing, spectre mitigations,
> process-per-origin, etc?
>
> This last is particularly concerning in terms of API surface, because
> interfacing with a multiprocess embedded browser might be quite different
> from interfacing with a single-process one...

As the proposal doesn't address this explicitly, I can only speculate
(no pun intended) as to the author's intentions, but I would assume
that the web platform implementation's usual policies would apply;
that is, if its policy is to spin up a new process for every origin,
then it will do so when used via web_view as well. (Of course, library
vendors may expose vendor- or platform-specific ways to tweak the
behaviour of the implementation (think "flipping prefs") if there's
demand for that.)

The proposal hasn't been presented to the committee yet, so I can't
speak to the committee's thoughts either, but I predict that there
would be opposition to a design that fundamentally lacks security
protections that would be present when using the web platform
implementation in a usual browser context.

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

Re: C++ standards proposal for a embedding library

[Botond Ballo]

On Wed, Jul 18, 2018 at 5:01 PM, Boris Zbarsky  wrote:
> On 7/18/18 4:54 PM, Botond Ballo wrote:
>>
>> Either to include one, or to be able to find and use one provided by
>> the OS/platform.
>
>
> Ah, ok.
>
> And in the latter case, to disable whatever network stack the OS-provided
> thing has, if any, and substitute its own, right?

I assume you're referring to the set_uri_scheme_handler() function in the API.

My reading of the proposal is that that's an extension mechanism for
the program to be able to override handling of standard URI schemes,
or invent new ones (such as for serving a page from a string in the
C++ program's memory), but if e.g. the program does not override the
"http" URI scheme, the OS-provided implementation's default handler
(including the network stack) would be used.

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

Re: C++ standards proposal for a embedding library

[Botond Ballo]

On Wed, Jul 18, 2018 at 4:13 PM, Boris Zbarsky  wrote:
> Am I correct in my reading that this would require the C++ standard library
> to include an implementation of the web platform?

Either to include one, or to be able to find and use one provided by
the OS/platform.

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

Re: C++ standards proposal for a embedding library

[Botond Ballo]

On Wed, Jul 18, 2018 at 3:32 PM, Jeff Gilbert  wrote:
> It feels like the committee is burnt out on trying to solve the
> general library problem, but contemplating something massively complex
> like this instead doesn't follow, and is an answer to the wrong
> question.
>
> Make it easier to integrate libraries and we wouldn't see kludge
> proposals like this.

Could you elaborate on the "complexity" and "kludge" aspects?

One of the main complaints about the 2D graphics proposal was that it
was trying to create a new spec in a space where there are existing
mature specs, and that the committee as a group doesn't necessarily
have the depth of domain expertise in graphics necessary to specify a
library like this. This web_view proposal attempts to address that
concern by leveraging existing graphics and other specs from web
standards. So, in a sense, the committee is trying to avoid dealing
with complexity / reuse the work that others have done to tackle the
complexity inherent in the problem space.

If you're referring to the embedding mechanism / API itself being
complex, it would be useful to elaborate on why. The API surface in
the proposed library seems to be quite small.

It's also worth noting that there is prior art in this space in the
form of e.g. the QtWebView and wxWebView APIs, which I believe are
fairly popular in cross-platform C++ applications, suggesting a demand
for this sort of library.

Note that I'm not necessarily advocating for this proposal; I'm just
trying to understand the concerns / feedback better so that I can
communicate them to the proposal authors effectively. If you would
prefer to communicate the concerns to the authors directly, please
feel free to do so.

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

C++ standards proposal for a embedding library

[Botond Ballo]

Hi everyone,

With the proposal for a standard 2D graphics library now on ice [1],
members of the C++ standards committee have been investigating
alternative ways of giving C++ programmers a standard way to write
graphical and interactive applications, in a way that leverages
existing standards and imposes a lower workload on the committee.

A recent proposal along these lines is for a standard embedding
facility called "web_view", inspired by existing embedding APIs like
Android's WebView:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html

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 welcome.

Thanks!
Botond

[1] 
https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Botond Ballo]

My blog post about what happened at this meeting is now live:

https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/

Cheers,
Botond


On Tue, May 22, 2018 at 6:35 PM, Botond Ballo  wrote:
> Hi everyone!
>
> The next meeting of the C++ Standards Committee will be June 4-9 in
> Rapperswil, Switzerland.
>
> This is going to be a pivotal meeting, with go / no-go decisions
> expected for several highly-anticipated C++20 features, including a
> subset of Modules; Coroutines; Ranges; and "natural syntax" Concepts /
> abbreviated function templates. A discussion of whether or not to
> continue efforts to standardize 2D Graphics is also scheduled (see
> arguments for [1] and against [2]). In addition, work will continue on
> various Technical Specifications that are in flight (including,
> notably, Reflection), and processing the large influx of new language
> and library feature proposals.
>
> 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 [3]), and the list of proposals being
> considered by the committee (new ones since the last meeting can be
> found here [4] and here [5]).
>
> I will be attending this meeting, hanging out in the Evolution Working
> Group (where new language features are discussed at the design level)
> as usual. As always, if there's anything you'd like me to find out for
> you at the meeting, or any feedback you'd like me to communicate,
> please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0988r0.pdf
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html
> [3] 
> https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/
> [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#mailing2018-02
> [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#mailing2018-04
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Botond Ballo]

On Wed, May 23, 2018 at 4:05 PM, Jet Villegas  wrote:
> I'd rather see the committee focus on things like object lifetime management
> so we don't have to port everything to Rust just to get basic memory safety
> guarantees. How much leverage do we have to push on that?

I assume you mean "push for better object lifetime management" rather
than "push against the 2D graphics proposal".

The only current proposal that I'm aware of in this area is P0936R0
("Bind Returned/Initialized Objects to the Lifetime of Parameters")
[1]. This aims to extend C++'s lifetime extension rules to "see
through" suitably annotated function / constructor calls, such that
objects bound to parameters of such a function / constructor are kept
alive for the lifetime of the return value / constructed object (so
the annotation basically means "this function returns an object /
constructs an object that refers to its parameters, and therefore that
object should not outlive the parameters").

This is far from a "borrow checker" (indeed, it doesn't *catch*
lifetime errors, it *avoids* them by making certain objects live
longer), but it may be a step in the right direction. I would be
interested to hear some opinions on this proposal from C++ Mozilla
engineers: do we think a proposal like this would materially improve
our C++ usage from an ergonomic and/or safety perspective?

If we like this proposal, we can certainly advocate for it when it's
presented, and vote for it if it comes up for a vote. (Procedurally,
the proposal was submitted prior to the previous meeting, and was not
looked at during the previous meeting because the Evolution Working
Group has a backlog of proposals. It will, hopefully, be looked at
during this coming meeting.) I will also keep a close eye on the
discussion, and report back any counter-arguments / concerns so we can
discuss and potentially respond to them. (So far, the main concern
I've heard is that by things "just working" without explicit lifetime
management more often, we would be lulling C++ programmers into a
false sense of safety.)

Beyond that, we could consider authoring additional proposals in this
area. As this is a tricky area of the language, we may want to
consider prototyping any proposal (either as a pure library, or via
modifications to our clang plugin) prior to submitting it.

There is also work being done in this area outside the formal
standards process, in the form of the C++ Core Guidelines [2] (some of
which can be checked statically) and the accompanying Guideline
Support Library [3], and in the form of Microsoft's lifetime checker
[4], though that seems to be progressing very slowly, and even though
I ask for an update at every meeting, I haven't seen much of substance
there.

Cheers,
Botond

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf
[2] https://github.com/isocpp/CppCoreGuidelines
[3] https://github.com/Microsoft/GSL
[4] 
https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-guidelines-checkers-preview-of-the-lifetime-safety-checker/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Upcoming C++ standards meeting in Rapperswil, Switzerland

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee will be June 4-9 in
Rapperswil, Switzerland.

This is going to be a pivotal meeting, with go / no-go decisions
expected for several highly-anticipated C++20 features, including a
subset of Modules; Coroutines; Ranges; and "natural syntax" Concepts /
abbreviated function templates. A discussion of whether or not to
continue efforts to standardize 2D Graphics is also scheduled (see
arguments for [1] and against [2]). In addition, work will continue on
various Technical Specifications that are in flight (including,
notably, Reflection), and processing the large influx of new language
and library feature proposals.

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 [3]), and the list of proposals being
considered by the committee (new ones since the last meeting can be
found here [4] and here [5]).

I will be attending this meeting, hanging out in the Evolution Working
Group (where new language features are discussed at the design level)
as usual. As always, if there's anything you'd like me to find out for
you at the meeting, or any feedback you'd like me to communicate,
please let me know!

Finally, I encourage you to reach out to me if you're thinking of
submitting a proposal to the committee. I'm always happy to help with
formulating and, if necessary, presenting a proposal.

Cheers,
Botond


[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0988r0.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html
[3] 
https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#mailing2018-02
[5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#mailing2018-04
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Botond Ballo]

On Fri, Apr 13, 2018 at 11:06 AM, Emilio Cobos Álvarez  wrote:
>> If we are going to have brace-initialization intermixed with
>> list-initialization (i.e. parentheses) in our codebase, I think we
>> should prefer no space prior to the brace, for consistency.
>
> Hmm, consistency with parenthesis I guess, but not with other things that
> use braces, like conditionals or other kind of declarations (where we use a
> space after the paren, for example), or lambdas where we use `mutable {`,
> etc.

Braces are used for a variety of purposes in C++. I think it makes
more sense to adapt the style to the purpose, than to try to enforce a
common style across all kinds of brace uses. We already do this; for
example, some uses of braces go on their own line, and others don't.

In this case, I think it makes sense for braces used for
initialization to be consistent with parentheses used for
initialization.

> Also, I guess per that argument we should use `mIsRootDefined{false}`
> instead of `mIsRootDefined{ false }`.

+1. `mIsRootDefined{false}` is what I've been using in constructor initializers.

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

Recent C++ standards meeting in Jacksonville, Florida

[Botond Ballo]

Hi everyone!

The week of March 12th I was at a meeting of the C++ Standards
Committee in Jacksonville, Florida. (Apologies for forgetting to
announce the meeting in advance, as I've done for previous meetings.)

Exciting progress was made at this meeting, as we approved new
features for C++20 and made progress on various Technical
Specifications, including Modules. Please see my blog post [1] for a
detailed account.

If you're interested in keeping up with C++ standardization, in
addition to reading my blog posts about meetings I encourage you to
look at the proposals being considered, the latest of which can be
found here [2].

As always, feel free to reach out to me with feedback about a
proposal, or if you're considering submitting a proposal of your own.

Cheers,
Botond

[1] 
https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/
[2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of "remote XUL"

[Botond Ballo]

On Tue, Mar 27, 2018 at 11:48 AM, Dave Townsend  wrote:
> My understanding is that it has been effectively unsupported for some time
> anyway so I think we should just go ahead and disable it altogether at this
> point. If we need bits for automated tests then we should work to switch
> tests away from those if we can.

Some rendering codepaths are only exercised by XUL.

For example, in bug 1205630 I fixed a tab-bar rendering issue, and I
had to write a XUL reftest as my regression test, because that's the
only thing I could get to exercise the affected code. I think it's
important that, as long as our browser UI uses the relevant XUL
features, the corresponding test coverage remains in place.

In turn, being able to load a XUL page locally (which I've been doing
with "dom.allow_XUL_XBL_for_file", not sure if there's another way),
is useful for writing such a XUL test.

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

C++ Developer Survey "Lite"

[Botond Ballo]

Hi folks,

The Standard C++ Foundation (the nonprofit which organizes CppCon,
provides some support for ISO C++ standards meetings, and promotes
standard C++ in other ways) is running a short (1 page / 16 questions)
C++ developer survey to help understand how developers use C++, what
are some of the persistent difficulties with it, and in particular,
what people would like to see in future standardization efforts.

While the survey is not officially affiliated with the ISO C++
standards committee, it's likely that people active in C++
standardization will look at the results, and it may impact their
prioritization / assessment of standards proposals.

If you're a C++ developer and care about the future of the language, I
encourage you to fill out the survey:

https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

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

Intent to ship: overscroll-behavior

[Botond Ballo]

I would like to ship support for the 'overscroll-behavior' CSS
property (formerly called 'scroll-boundary-behavior') in Firefox 59.

Preference behind which the feature was developed:
  layout.css.overscroll-behavior.enabled

"Intent to implement" thread:
  https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg23947.html

Tracking bug for shipping:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1428879

Draft spec:
  https://wicg.github.io/overscroll-behavior/

  There have not been any significant changes to the spec since
  the "Intent to implement" email, except for the change of name
  from 'scroll-boundary-behavior' to 'overscroll-behavior'.

Support by other browser engines:
  Blink: Shipping in Chrome 63 [1]
  Edge: Public support [2]
  WebKit: No public signals

Testing:
  The feature has a manual web-platform-test [3].
  The Chromium folks are working on upstreaming
  an automated web-platform-test [4].

Example:

  #chatbox {
/* Excess scrolling on the chatbox will not be handed off
to its parent scrollable .*/
overscroll-behavior: contain;
  }

  See [5] for more examples.

Cheers,
Botond

[1] https://www.chromestatus.com/features/5734614437986304
[2] 
https://discourse.wicg.io/t/generic-scroll-chaining-prevention-mechanism-or-expand-standardize-ms-scroll-chaining/1811/5?u=majidvp
[3] 
https://searchfox.org/mozilla-central/rev/cf149b7b63ff97023e28723167725e38cf5df757/testing/web-platform/tests/css/cssom-view/overscrollBehavior-manual.html
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=762054
[5] https://wicg.github.io/overscroll-behavior/#motivating-examples
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Refactoring proposal for the observer service

[Botond Ballo]

On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto  wrote:
> - It would make trivially simple to document the topics, their subjects
> and payloads. Potentially this could even be integrated with our
> generated documentation and code search tools making developer lives a
> lot easier.

+1. Not having a place to "declare" / document observer messages has
been one of the things bothering me about the observer service for a
long time.

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

Re: Intent to implement: scroll-boundary-behavior

[Botond Ballo]

This has now landed on the Nightly channel.

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

Re: Hiding 'new' statements - Good or Evil?

[Botond Ballo]

I think it makes sense to hide a 'new' call in a Make* function when
you're writing an abstraction that handles allocation *and*
deallocation.

So MakeUnique makes sense, because UniquePtr takes ownership of the
allocated object, and will deallocate it in the destructor. MakeRefPtr
would make sense for the same reason.

But in cases where a library facility is not taking ownership of the
object, and thus the user will need to write an explicit 'delete', it
makes sense to require that the user also write an explicit 'new', for
symmetry.

NotNull is a bit of a weird case because it can wrap either a raw
pointer or a smart pointer, so it doesn't clearly fit into either
category. Perhaps it would make sense for MakeNotNull to only be
usable with smart pointers?

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

Re: Intent to implement: scroll-boundary-behavior

[Botond Ballo]

For those following along, please note that this CSS property has been
renamed from 'scroll-boundary-behavior' to 'overscroll-behavior'.

The spec is accordingly now at [1], and the preference for controlling
the feature has changed correspondingly.

Cheers,
Botond

[1] https://wicg.github.io/overscroll-behavior/
___
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

Re: TypeError: %d format: a number is required, not float when building Firefox 52.4.1esr in Linux from Scratch

[Botond Ballo]

> File
> "/root/sources/firefox-52.4.1esr/toolkit/components/telemetry/gen-event-data.py",
> line 82, in write_common_event_table
> e.dataset),
> TypeError: %d format: a number is required, not float

I haven't come across this error before, nor did a quick search
turn up anything. I would suggest filing a bug report in the
Toolkit :: Telemetry component [1], and hopefully people more
familiar with that code can point you in the right direction.

> The system I'm building on has 2 1GHz Pentium III processors and 1GB of RAM.

Note that you may have trouble linking Firefox on a system
with 1 GB RAM. The build documentation says a minimum
of 2 GB is required [2] (and I'm not even sure that that's up
to date; the developer machines we build on in practice
have >= 4 GB RAM).

Cheers,
Botond

[1] 
https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit=Telemetry
[2] 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Linux_Prerequisites
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Upcoming C++ standards meeting in Albuquerque, New Mexico

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee will be November 6-11
in Albuquerque, New Mexico.

The focus of this meeting will be features targeting C++20 and
Technical Specifications (TS). I expect significant emphasis will be
placed on the Modules TS, whose Proposed Draft [1] has been published
earlier this year, and which has garnered a wide range of feedback
that the Committee will now address. Other exciting areas to watch
include Concepts, which has been merged into C++20 with some
modifications (compared to the TS published in 2015) [2] motivated by
implementation and use experience, and for which more potential
modifications have been proposed; Reflection, for which an initial set
of facilities [3] is headed towards a TS while more ambitious features
are being proposed [4]; and the standard library, for which a
"refresh" / v2 is being contemplated, with the Ranges TS [5] as a
possible starting point.

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 [6]), and the list of proposals being
considered by the committee (new ones since the last meeting can be
found here [7] and here [8]).

I will be attending this meeting, hanging out in the Evolution Working
Group (where new language features are discussed at the design level)
as usual. As always, if there's anything you'd like me to find out for
you at the meeting, or any feedback you'd like me to communicate,
please let me know!

Finally, I encourage you to reach out to me if you're thinking of
submitting a proposal to the committee. I'm always happy to help with
formulating and, if necessary, presenting a proposal.

Cheers,
Botond


[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4689.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0734r0.pdf
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0194r4.html
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r2.pdf
[5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4671.pdf
[6] 
https://botondballo.wordpress.com/2017/08/02/trip-report-c-standards-meeting-in-toronto-july-2017/
[7] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/#mailing2017-07
[8] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/#mailing2017-10
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: scroll-boundary-behavior

[Botond Ballo]

Summary:
  A CSS property that allows web developers to control what scroll
  boundary actions performed by the browser (such as scroll handoff
  to a parent scrollable element, visual overscroll effect, swipe
  navigation, etc.) should apply to a scrollable element.

Tracking bug:
  https://bugzilla.mozilla.org/show_bug.cgi?id=951793

Draft spec:
  https://wicg.github.io/scroll-boundary-behavior/

Platform coverage:
  The CSS property will be supported on all platforms. The browser's
  default boundary actions may vary from platform to platform (for
  example, Firefox currently shows a visual overscroll effect on
  Android but not on desktop platforms).

Estimated target release:
  Behind a pref: Firefox 58 (estimated)
  Enabled by default: TBD

Preference behind which this will be implemented:
  layout.css.scroll-boundary-behavior.enabled

DevTools support:
  I don't believe any special support is required beyond adding the
  property to the list of properties surfaced by the inspector.

Support by other browser engines:
  Blink: Yes, will ship in Chrome 63 [1]
  Edge: Public support [2]
  WebKit: No public signals

Tests:
  The Blink implementers have upstreamed a web-platform-test [3].
  I plan to look into getting that to run on Firefox. Additional test
  cases can be added to it if necessary.

Cheers,
Botond

[1] https://www.chromestatus.com/features/5734614437986304
[2] 
https://discourse.wicg.io/t/generic-scroll-chaining-prevention-mechanism-or-expand-standardize-ms-scroll-chaining/1811/5?u=majidvp
[3] 
http://searchfox.org/mozilla-central/rev/d30462037ffea383e74c42542c820cf65b2b144e/testing/web-platform/tests/cssom-view/scrollBoundaryBehavior-manual.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Experimenting with a shared review queue for Core::Build Config

[Botond Ballo]

On Wed, Oct 11, 2017 at 2:37 PM, Chris Cooper  wrote:
> On Wed, Oct 11, 2017 at 1:46 PM, Nathan Froyd  wrote:
>> Does this user have a bugzilla :alias so that folks submitting patches
>> via MozReview or similar can just write r=build-peer or something,
>> rather than having to manually select the appropriate shared queue
>> after submitting their patch for review?
>
> I see this as an added efficiency, so I'll see how much effort it is
> to set this up. The people behind MozReview are explicitly not
> expending effort there right now in favor of phabricator though.

It does not require any setup on the MozReview side - you just need to
add ":build-peer" (or whatever the chosen alias) to the "Real name"
field of the user's Bugzilla profile, and MozReview will autodetect
it.

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

Re: C++ function that the optimizer won't eliminate

[Botond Ballo]

Not immediately useful to us, but there is a C++ standards proposal in
the works for a standard library function along these lines:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0412r0.html

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

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

[Botond Ballo]

Will submitting to try from MozReview (or Phabricator once that
replaces MozReview) still work? I think there is important value in
being able to submit to try without a local checkout.

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

Re: Reminder on Try usage and infrastructure resources

[Botond Ballo]

On Thu, Sep 14, 2017 at 4:54 PM, Mike Hommey  wrote:
> Maybe it's time to kill the `all` flag, at least for -p. Why? For the
> combined reason that you're saying we shouldn't be using it, and that
> it's actually *not* running every platform.

I think "-p all" is still useful for "T pushes" (and it sounds like
build jobs aren't the main concern resource-wise).

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

Re: Eiminating nsIDOM* interfaces and brand checks

[Botond Ballo]

On Fri, Sep 1, 2017 at 12:11 PM, Ehsan Akhgari  wrote:
> How about this slight variation:
>
> HTMLEmbedElement.isInstanceOf(obj)
>
> instead of "is"?

Isn't that backwards, though? HTMLEmbedElement isn't an instance of
'obj', 'obj' is an instance of HTMLEmbedElement :)

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

APZ autoscrolling enabled on Nightly channel

[Botond Ballo]

Hi everyone,

APZ autoscrolling (bug 1390247) is now enabled by default on the
Nightly channel.

For those not familiar with autoscrolling, it's a scrolling mechanism
activated by middle-clicking the mouse, which causes an "anchor" to
appear on the screen, and moving the mouse away from the anchor. (It's
enabled by default on Windows, and can be enabled on Mac and Linux by
checking "Enable autoscrolling" in about:preferences).

Until now, autoscrolling was driven by the content process main
thread, which meant it was susceptible to jank on pages that are slow
to paint or run heavy script. APZ autoscrolling fixes that by driving
it from the compositor, allowing it to be smoother. (At the same time,
like other async scrolling methods, APZ autoscrolling can trigger
checkerboarding if you scroll sufficiently fast on a sufficiently long
page.)

If you notice any regressions related to autoscrolling on the Nightly
channel, please file bugs blocking bug 1390247.

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

Re: Upcoming C++ standards meeting in Toronto, Canada

[Botond Ballo]

On Wed, Jul 5, 2017 at 7:55 PM, Botond Ballo <bba...@mozilla.com> wrote:
> I will be there, hanging out in the Evolution Working
> Group as usual, and blogging about the meeting afterwards.

If you're interested in what happened at this meeting, my blog post
about it is now live:

https://botondballo.wordpress.com/2017/08/02/trip-report-c-standards-meeting-in-toronto-july-2017/

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

Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Botond Ballo]

On Mon, Jul 31, 2017 at 3:40 AM, Enrico Weigelt, metux IT consult
 wrote:
> On 31.07.2017 09:23, Cameron McCormack wrote:
>> Firefox patches should be submitted via Bugzilla, rather than by email
>> to dev-platform.  Please see:
>>
>> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_-_Get_your_code_reviewed
>
> Is there a way to submit via mail ? Or some git-send-email counterpart ?
>
> Always going through the web frontend manually would be pretty time
> consuming ...

I've already answered this [1]: patches can be submitted via the
command-line using "hg push review". Ralph Giles also pointed you to a
git-based equivalent [2].

Cheers,
Botond

[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/goLGqnPfAMI/wSes1D1gCAAJ
[2] 
https://groups.google.com/d/msg/mozilla.dev.platform/goLGqnPfAMI/B7ueR4tgCAAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: sccache as ccache

[Botond Ballo]

On Wed, Jul 26, 2017 at 9:05 AM, Ted Mielczarek  wrote:
> If you build Firefox on Linux or OS X you can (and
> should) use sccache in place of ccache for local development.

Can sccache be used in conjunction with icecc [1]?

I currently use the two together by having the following in my .mozconfig:

  ac_add_options --with-ccache
  mk_add_options 'export CCACHE_PREFIX=icecc'
  mk_add_options 'export CCACHE_CPP2=yes'

Is there an equivalent / similar setup with sccache?

Thanks,
Botond

[1] 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Using_Icecream
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Correct format specifier for size_t

[Botond Ballo]

We have a mozilla/SizePrintfMacros.h header which defines "PRIuSIZE"
for this purpose.

Cheers,
Botond

On Tue, Jul 25, 2017 at 12:43 PM, Honza Bambas  wrote:
> In light of using PRxx formatting macros from inttypes.h, what is the right
> approach to printf size_t types (like our nsTArray::Length()) ?
>
> Not sure if to use "%zu" directly.
>
> Thanks.
> -hb-
>
> ___
> 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: Announcing MozillaBuild 3.0 Release

[Botond Ballo]

On Mon, Jul 24, 2017 at 6:21 PM, Enrico Weigelt, metux IT consult
 wrote:
> Is there an automatic interface for patch submission (something
> similarily easy like git-send-mail) ? Having to click through websites
> manually is just very time consuming.

With MozReview [1], you can submit patches from the command line via a
simple "hg push review".

Cheers,
Botond

[1] 
https://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview-user.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: who uses idl stuff

[Botond Ballo]

> could anyone please give me some insight, where the the IDLs
> (and the code generated from them) are actually used ?
>
> Javascript bindings ?

They are typically used as an interface between C++ and JS code.

As an example, consider nsIDocShell.idl [1]. This defines an interface
named "nsIDocShell" with a bunch of attributes and methods.

The IDL compiler generates a C++ binding for this, in the form of a
header file [2] that declares an abstract base class, also named
"nsIDocShell", which has pure virtual C++ methods corresponding to the
IDL methods and attributes (in the case of attributes, a getter/setter
pair is generated).

There is then a concrete C++ class, nsDocShell [3], which inherits
from nsIDocShell and implements the methods.

Finally, the interface is made available for JS code to use, which can
access its methods, attributes, etc. [4] The methods can also be
called from C++ code [5], though typically there are at least some JS
callers, otherwise the IDL wouldn't be necessary.

Let me know if that answers your question.

Cheers,
Botond

[1] 
http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/docshell/base/nsIDocShell.idl#58
[2] 
http://searchfox.org/mozilla-central/source/__GENERATED__/dist/include/nsIDocShell.h
[3] 
http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/docshell/base/nsDocShell.h
[4] 
http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/browser/base/content/content.js#603
[5] 
http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/accessible/generic/DocAccessible.cpp#355
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Phabricator Update, July 2017

[Botond Ballo]

On Wed, Jul 12, 2017 at 11:54 AM, Byron Jones  wrote:
>
>> Consider that we are talking about "turning off" mozreview now.  Will all
>> the bugzilla links to those reviews go dead?  Or do we have to maintain a
>> second service in read-only mode forever?
>
> the patches will be archived in some form.
>
> how this looks is yet to be fully fleshed out - ideas currently include
> archiving and updating bugzilla to point to their new location (eg. s3), or
> uploading patches directly to bugzilla.

Note that merely uploading a MozReview patch to bugzilla potentially
loses some information: in MozReview, all of the patch's ancestors
were available in a repository such that you could pull the patch and
apply it locally without having to rebase and potentially encounter
conflicts. That's not true of plain patches uploaded to bugzilla.

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

PSA: Use MOZ_DEFINE_ENUM to avoid having to add sentinel enumerators

[Botond Ballo]

Today I landed bug 1371771 [1] (on inbound at the time of writing
this), which adds a new MOZ_DEFINE_ENUM macro to MFBT.

This macro defines an enumeration, together with a constant that
stores the number of enumerators (and, in addition, another constant
that stores the highest enumerator).

For example,

  MOZ_DEFINE_ENUM(Foo, (A, B, C));

will expand to:

  enum Foo { A, B, C };
  constexpr size_t kFooCount = 3;
  constexpr Foo kHighestFoo = Foo(kFooCount - 1);

This avoids having to give your enumeration a "sentinel" value for
purposes such as IPC serialization (since you can just use the
constant generated by the macro instead), which in turn means you
don't need special handling for a sentinel value in switch statements
and such.

There are also some variants of the macro to support use cases such as
enum classes, enums with a specified underlying type, and enums at
class scope. See the documentation in mfbt/DefineEnum.h for more
details and motivation.

Consider using MOZ_DEFINE_ENUM instead of a sentinel enumerator in
newly added enumerations, and, if you're so inclined, consider
refactoring existing enumerations to use MOZ_DEFINE_ENUM instead of a
sentinel (I've already done so for enumerations in gfx/layers in bug
1377020 [2]).

Cheers,
Botond

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

Upcoming C++ standards meeting in Toronto, Canada

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee will be July 10-15 in
Toronto, Canada.

With C++17 wrapped up, this meeting will be focused full-steam on
C++20, with a particular emphasis on the big-ticket items the
committee is trying hard to get into C++20: Concepts, Modules, Ranges,
and Networking (some of these are already published as Technical
Specifications).

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 [1]), and the list of proposals being
considered by the committee (new ones since the last meeting can be
found here [2] and here [3]).

In addition, since this time around the meeting is in Toronto, where
we have a significant number of Mozillians, I'd like to take this
opportunity to remind you that committee meetings are open for members
of the public to attend as observers. Whether you're interested in a
particular proposal or topic, or just curious about the committe in
general, you're welcome to sit in on part or all of the meeting. (See
[4] for info on location and times. If you are interested in a
particular proposal or topic, feel free to reach out to me and I'll
let you know when, specifically, it will be discussed.)

In any case, I will be there, hanging out in the Evolution Working
Group as usual, and blogging about the meeting afterwards. If you're
not able to make it yourself, and would like me to find out something
for you, or communicate feedback on a proposal, please let me know!

Cheers,
Botond

[1] 
https://botondballo.wordpress.com/2017/03/27/trip-report-c-standards-meeting-in-kona-february-2017/
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/#mailing2017-03
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/#mailing2017-06
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4636.pdf
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is it OK to make allocations that intentionally aren't freed? (was: Re: Is Big5 form submission fast enough?)

[Botond Ballo]

On Fri, May 19, 2017 at 10:38 PM, Nicholas Nethercote
 wrote:
> There's also a pre-processor constant that we define in Valgrind/ASAN/etc.
> builds that you can check in order to free more stuff than you otherwise
> would. But I can't for the life of me remember what it's called :(

It looks like some code checks for MOZ_ASAN and MOZ_VALGRIND.

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

Re: Have you run 'mach bootstrap' lately?

[Botond Ballo]

On Fri, May 12, 2017 at 3:00 PM, Andrew McCreight
 wrote:
> On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek  wrote:
>
>> On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
>> > Would it be possible to add a check like:
>> > "You haven't updated your local configuration since XX days, please
>> > consider running
>> > mach bootstrap ?"
>>
>> We've had mach produce nag messages like that in the past and they have
>> been universally disliked, FWIW.
>>
>
> Obviously it has less users, but moz-git-tools has a similar thing and I
> find it handy and nobody has complained about it, AFAIK.
> https://lists.mozilla.org/listinfo/dev-platform

Also, the previous nag message actually prevented you from proceeding
to |mach build| unless you employed an obscure bypass. I think that's
what people were most annoyed about, and would look upon an optional
reminder more favourably.

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

Re: Rationalising Linux audio backend support

[Botond Ballo]

On Tue, Mar 28, 2017 at 11:06 PM, Jan Beich <jbe...@freebsd.org> wrote:
> Botond Ballo <bot...@mozilla.com> writes:
>
>> Anyways, there is no conflict between supporting ALSA and supporting
>> 5.1 sound. As has been mentioned earlier in the thread, ALSA has since
>> added support for 5.1, and so IIUC it's just our wrapper library
>> (libcubeb) that needs the support added.
>
> When did this happen?

I was going off of statements made in bug 1345661, such as in comment
63: "ALSA supports 5.1 audio perfectly well; I'm using it daily." [1],
and a quick Google search suggests ALSA supports 5.1 audio as well.

> Bug 1341108 still stands.

It looks like that bug concerns 5.1 support in the libcubeb ALSA
backend, not in ALSA itself.

Cheers,
Botond

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1345661#c63
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Botond Ballo]

On Tue, Mar 28, 2017 at 6:49 PM,   wrote:
> Why does a  BROWSER need 5.1 or x.y sound???

The web platform is intended to be a competitive alternative to native
platforms. That means that whatever native applications can do, we'd
like web applications to be able to do as well, and that includes
playing 5.1 sound.

As an (important) example, I imagine there is a growing segment of
users who watch T.V. shows and movies through a computer running
Netflix in a browser, and some of those users want the browser to be
able to play 5.1 sound.

Anyways, there is no conflict between supporting ALSA and supporting
5.1 sound. As has been mentioned earlier in the thread, ALSA has since
added support for 5.1, and so IIUC it's just our wrapper library
(libcubeb) that needs the support added.

> and remove your spying telemetry too

First, I don't see how collecting aggregate technical statistics like
what fraction of our Linux users use PulseAudio and what fraction use
ALSA, is a threat to anyone's privacy or otherwise constitutes
"spying".

Second, continuing to opt out of telemetry will just make problems
like this worse. As was stated in this thread, one of the
justifications for removing ALSA support was that the telemetry
numbers showed a very little ALSA usage. If more ALSA users had
telemetry enabled, perhaps the outcome would have been different.

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

Re: Upcoming C++ standards meeting in Kona, Hawaii

[Botond Ballo]

If you're interested in what happened at this meeting, my blog post has details:

https://botondballo.wordpress.com/2017/03/27/trip-report-c-standards-meeting-in-kona-february-2017/

Cheers,
Botond

On Fri, Feb 24, 2017 at 1:53 PM, Botond Ballo <bba...@mozilla.com> wrote:
> Hi everyone!
>
> The next meeting of the C++ Standards Committee will be February 27 -
> March 4 in Kona, Hawaii.
>
> I've blogged in detail about the last meeting here [1]. The focus of
> that meeting was polishing the C++17 feature set by addressing
> comments from national standards bodies on the initial draft of the
> C++17 standard that was circulated last summer.
>
> This meeting will continue that work, while also moving forward the
> in-progress Technical Specifications (notable among them, Ranges,
> Networking, Coroutines, and - my favourite - Modules), and then
> looking more strategically towards C++20. (Notably, the pre-meeting
> mailing contains a paper called "To boldly suggest an overall plan to
> C++20" [2].)
>
> For a full list of new papers submitted to the committee since the
> last meeting, see [3] and [4].
>
> I will be attending this meeting, hanging out in the Evolution Working
> Group (where new language features are discussed at the design level)
> as usual. As always, if there's anything you'd like me to find out for
> you at the meeting, or any feedback you'd like me to communicate,
> please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
> [1] 
> https://botondballo.wordpress.com/2016/11/25/trip-report-c-standards-meeting-in-issaquah-november-2016/
> [2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0592r0.html
> [3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/#mailing2016-11
> [4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/#mailing2017-02
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: ScrollTimeline

[Botond Ballo]

> Is it possible to use this, or is there a similar proposal, for linking 
> animation timeline to other user-controlled means of interacting with the UI?
>
> I'm thinking primarily about things like:
>
>  - drag - the percentage of the distance between the source and target 
> linked to the animation timeline
>  - touch events - unfold or move an element with a thumb on mobile triggers 
> an animation linked to the percentage of the distance between folded/unfolded.

Web Animations was designed with the possibility of extending it with
other types of timelines in mind.

ScrollTimeline is one such extension, a timeline linked to scrolling.

What you describe sounds like other types of timelines, linked to user
gestures. There is mention of that on the wiki [1] [2], but no
concrete proposal that I'm aware of. I would imagine contributions to
the development of such a proposal would be welcome!

Cheers,
Botond

[1] 
https://wiki.mozilla.org/Platform/Layout/Extended_Timelines#Touch-based_scrubbing
[2] https://wiki.mozilla.org/Platform/Layout/Extended_Timelines#Other_timelines
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: ScrollTimeline

[Botond Ballo]

Summary:
  Scroll-linked animations are a way for web developers to write
  web animations whose progress is linked to scrolling rather than
  to time.
  ScrollTimeline is the JS API for creating scroll-linked animations
  (the spec also contains a CSS API, which will be implemented at
  a later time).

Bug:
  Tracking bug for scroll-linked animations: bug 1281348 [1]
  Tracking bug for the initial landing of ScrollTimeline: bug 1321428 [2]

Link to standard:
  https://wicg.github.io/scroll-animations/

  This spec is fairly unstable for the time being, and is likely to
  undergo significant changes before final standardization.
  However, I believe the core mechanism that I'm proposing to
  implement here is reasonably stable, and web developers will
  benefit from having it in a Firefox build so they can play around
  with it.

Platform coverage: where will this be available?
  All platforms.

Estimated or target release:
  Not known yet. Probably not very soon as the spec still needs
  to stabilize.

Preference behind which this will be implemented:
  dom.animations-api.scroll-driven.enabled

  Due to the early stage of standardization of this feature, it will
  initially only be available on Nightly _and_ behind a pref (that is,
  you need to be running Nightly and have the pref flipped to
  use it).

Is this feature enabled by default in sandboxed iframes?
  Yes

If allowed, does it preserve the current invariants in terms of what
sandboxed iframes can do?
  I believe so, but I'm not an authority on sandboxing.

DevTools bug:
  Bug 1350461

Do other browser engines implement this?
  Safari has originally proposed the CSS properties that this spec
  is based on [4], though I'm not aware of recent activity relating
  to it.

  Blink has a very similar proposal [5] which we expect will be
  consolidated into the WICG spec linked above.

Tests
  Currently just layout/reftests/async-scrolling/animation.
  Bug 1324605 tracks writing web platform tests.

Cheers,
Botond

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1281348
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1321428
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1350461
[4] https://lists.w3.org/Archives/Public/www-style/2014Sep/0135.html
[5] https://github.com/drufball/generalized-animations
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1324605
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Botond Ballo]

Now that this change has hit the release channel, we've started
receiving feedback from a wider range of users, a lot of it in bug
1345661 [1].

I believe the feedback in that thread brings some new information to
the table that we weren't aware of when this decision was made:

  - Based on the volume of the feedback we received, and the number
of duplicate bugs and so on, it appears that quoted telemetry data
underestimates the number of users who use ALSA. This is
corroborated by the fact that some of the affected distributions
disable telemetry in their Firefox packages.

  - A number of users, particularly those in the audiophile and music
production / recording communities, report technical reasons for
preferring ALSA over PulseAudio.

  - We've had an offer from someone to volunteer to maintain the
ALSA backend (bug 1345661 comment 52 [2]).

Based on this new information, might there be room to reconsider this decision?

Cheers,
Botond

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1345661
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1345661#c52

On Thu, Aug 25, 2016 at 8:56 AM, Randell Jesup  wrote:
>>I just landed some telemetry to measure the usage of all audio backends,
>>we'll have data soon.
>>
>>This was bug 1280630, and the probe is at [0]. This also measures
>>failures to open a stream and usage of backends that should not be used
>>on certain platform, like winmm on windows vista+.
>>
>>Also I support this proposal.
>
> We have some data now; in Aurora 50 it's 96.5%/3.5%, Nightly 51 is
> 98%/2%
>
> Of course, even Aurora users aren't necessarily "typical" users, but I
> imagine these will not move much in the favor of Alsa in Beta or
> release, and more likely move towards Pulse ("users" are more likely to
> be running plain-jane distros which have Pulse enabled by default - but
> we'll see).
>
> We'll start getting beta results in a few weeks.
>
> --
> Randell Jesup, Mozilla Corp
> remove "news" for personal email
> ___
> 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: Tracking bug for removals after XPCOM extensions are no more?

[Botond Ballo]

What will happen to WebExtension Experiments once these APIs start
being removed? My understanding is that WebExtension Experiments use
the same XPCOM APIs as XUL addons.

Cheers,
Botond

On Wed, Mar 15, 2017 at 8:00 AM, Henri Sivonen  wrote:
> On Mon, Mar 13, 2017 at 3:17 PM, Nathan Froyd  wrote:
>> We do not.
>
> OK. I filed one:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1347507
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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

Upcoming C++ standards meeting in Kona, Hawaii

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee will be February 27 -
March 4 in Kona, Hawaii.

I've blogged in detail about the last meeting here [1]. The focus of
that meeting was polishing the C++17 feature set by addressing
comments from national standards bodies on the initial draft of the
C++17 standard that was circulated last summer.

This meeting will continue that work, while also moving forward the
in-progress Technical Specifications (notable among them, Ranges,
Networking, Coroutines, and - my favourite - Modules), and then
looking more strategically towards C++20. (Notably, the pre-meeting
mailing contains a paper called "To boldly suggest an overall plan to
C++20" [2].)

For a full list of new papers submitted to the committee since the
last meeting, see [3] and [4].

I will be attending this meeting, hanging out in the Evolution Working
Group (where new language features are discussed at the design level)
as usual. As always, if there's anything you'd like me to find out for
you at the meeting, or any feedback you'd like me to communicate,
please let me know!

Finally, I encourage you to reach out to me if you're thinking of
submitting a proposal to the committee. I'm always happy to help with
formulating and, if necessary, presenting a proposal.

Cheers,
Botond

[1] 
https://botondballo.wordpress.com/2016/11/25/trip-report-c-standards-meeting-in-issaquah-november-2016/
[2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0592r0.html
[3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/#mailing2016-11
[4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/#mailing2017-02
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform