Re: Windows launcher process enabled by default on Nightly

[Jean-Yves Avenard]

Hi


On 2/10/2018 5:05 AM, Aaron Klotz wrote:


For various reasons we don't want to put escape hatches into any 
builds that we ship.


For local builds, if it would ease developer concerns over this 
feature, we can look into it. I have filed bug 1495628 for that purpose.


Seems that we can build with --disable-launcher-process to get around 
the issue. That seems good enough to me (though a dynamic pref/option 
would do better of course)

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

Re: Rust and --enable-shared-js

[Henri Sivonen]

On Mon, Sep 24, 2018 at 3:24 PM, Boris Zbarsky  wrote:
> On 9/24/18 4:04 AM, Henri Sivonen wrote:
>>
>> How important is --enable-shared-js? I gather its use case is making
>> builds faster for SpiderMonkey developers.
>
>
> My use case for it is to be able to use the "exclude samples from library X"
> or "collapse library X" tools in profilers (like Instruments) to more easily
> break down profiles into "page JS" and "Gecko things".

OK.

On Mon, Sep 24, 2018 at 1:24 PM, Mike Hommey  wrote:
>> How important is --enable-shared-js? I gather its use case is making
>> builds faster for SpiderMonkey developers. Is that the only use case?
>
> for _Gecko_ developers.

This surprises me. Doesn't the build system take care of not
rebuilding SpiderMonkey if it hasn't been edited? Is this only about
the link time?

What's the conclusion regarding next steps? Should I introduce
js_-prefixed copies of the four Rust FFI functions that I want to make
available to SpiderMonkey?

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Extension to integrate Searchfox features in Phabricator

[Marco Castelluccio]

I've built an (experimental) WebExtension to integrate some of the
Searchfox features into Phabricator.
I find it very useful to be able to search code while reviewing, but I
have to resort to opening a new
Searchfox tab and looking for the code that is being modified. This
extension makes my workflow much
more pleasant.

You can find it at
https://addons.mozilla.org/addon/searchfox-phabricator/ (the source code
is at
https://github.com/marco-c/mozsearch-phabricator-addon).

Currently, the extension does:
1) Highlight keywords when you hover them, highlighting them both in the
pre-patch and in the post-patch view;
2) When you press on a keyword, it offers options to search for the
definition, callers, and so on (the results are opened on Searchfox in a
new tab).

I'm planning to add support for sticky highlighting and blame
information (when hovering on the line number on the left side).

- Marco.

P.S.: The extension relies on parsing pages from Searchfox and from
Phabricator, so the maintenance might not be so easy. If there's enough
interest, I might keep maintaining it or talk with someone to make
Searchfox data accessible in an easier way.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extension to integrate Searchfox features in Phabricator

[Kartikaya Gupta]

Neat! I took a quick peek at your addon source and the stuff it's
relying on seems ok for now. At least, it's not anything we plan to
change anytime soon. If there are changes to searchfox that would make
your life easier in terms of expanding your addon, let me know and we
can discuss possibilities.

Cheers,
kats
On Tue, Oct 2, 2018 at 9:03 AM Marco Castelluccio
 wrote:
>
> I've built an (experimental) WebExtension to integrate some of the
> Searchfox features into Phabricator.
> I find it very useful to be able to search code while reviewing, but I
> have to resort to opening a new
> Searchfox tab and looking for the code that is being modified. This
> extension makes my workflow much
> more pleasant.
>
> You can find it at
> https://addons.mozilla.org/addon/searchfox-phabricator/ (the source code
> is at
> https://github.com/marco-c/mozsearch-phabricator-addon).
>
> Currently, the extension does:
> 1) Highlight keywords when you hover them, highlighting them both in the
> pre-patch and in the post-patch view;
> 2) When you press on a keyword, it offers options to search for the
> definition, callers, and so on (the results are opened on Searchfox in a
> new tab).
>
> I'm planning to add support for sticky highlighting and blame
> information (when hovering on the line number on the left side).
>
> - Marco.
>
> P.S.: The extension relies on parsing pages from Searchfox and from
> Phabricator, so the maintenance might not be so easy. If there's enough
> interest, I might keep maintaining it or talk with someone to make
> Searchfox data accessible in an easier way.
> ___
> 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: Rust and --enable-shared-js

[Luke Wagner]

(Sorry, I polled #jsapi about this issue back when you first posted and
then forgot to reply with the response.)

It doesn't seem like any SM devs use --enable-shared-js for their own
development but we do know that various embedders (e.g. GNOME) use the JS
shared library and so we'd like to keep that configuration tested and
working.  One hybrid option is thus:
 - drop support for building Gecko with --enable-shared-js (avoiding the
symbol conflict issue), but keep --enable-shared-js as a configure option
for JS shell builds
 - have at least one tier-1 --enable-shared-js JS shell build on automation
so that we at least keep it working

Cheers,
Luke


On Tue, Oct 2, 2018 at 7:25 AM Henri Sivonen  wrote:

> On Mon, Sep 24, 2018 at 3:24 PM, Boris Zbarsky  wrote:
> > On 9/24/18 4:04 AM, Henri Sivonen wrote:
> >>
> >> How important is --enable-shared-js? I gather its use case is making
> >> builds faster for SpiderMonkey developers.
> >
> >
> > My use case for it is to be able to use the "exclude samples from
> library X"
> > or "collapse library X" tools in profilers (like Instruments) to more
> easily
> > break down profiles into "page JS" and "Gecko things".
>
> OK.
>
> On Mon, Sep 24, 2018 at 1:24 PM, Mike Hommey  wrote:
> >> How important is --enable-shared-js? I gather its use case is making
> >> builds faster for SpiderMonkey developers. Is that the only use case?
> >
> > for _Gecko_ developers.
>
> This surprises me. Doesn't the build system take care of not
> rebuilding SpiderMonkey if it hasn't been edited? Is this only about
> the link time?
>
> What's the conclusion regarding next steps? Should I introduce
> js_-prefixed copies of the four Rust FFI functions that I want to make
> available to SpiderMonkey?
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
> ___
> 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

assignment between related nsCOMPtrs<> now works

[Andrew McCreight]

I've landed bug 1494765, which allows you to do assignments between
nsCOMPtrs for classes that are related by subtyping.

For instance:

class A { ... ];
class B : public A { ... };

nsCOMPtr b = ...;
nsCOMPtr a = b; // this works now

This is a step towards bug 1493226, which is going to statically ban
trivial do_QueryInterface calls like this:

nsCOMPtr a2 = do_QueryInterface(b);
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: assignment between related nsCOMPtrs<> now works

[Bobby Holley]

This is awesome - great papercut fix. Thanks Andrew!

Any chance of fixing it for RefPtr too?

On Tue, Oct 2, 2018 at 9:30 AM Andrew McCreight 
wrote:

> I've landed bug 1494765, which allows you to do assignments between
> nsCOMPtrs for classes that are related by subtyping.
>
> For instance:
>
> class A { ... ];
> class B : public A { ... };
>
> nsCOMPtr b = ...;
> nsCOMPtr a = b; // this works now
>
> This is a step towards bug 1493226, which is going to statically ban
> trivial do_QueryInterface calls like this:
>
> nsCOMPtr a2 = do_QueryInterface(b);
> ___
> 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: assignment between related nsCOMPtrs<> now works

[Andrew McCreight]

On Tue, Oct 2, 2018 at 9:33 AM Bobby Holley  wrote:

> This is awesome - great papercut fix. Thanks Andrew!
>
> Any chance of fixing it for RefPtr too?
>

That should already work:
https://searchfox.org/mozilla-central/rev/6ddb5fb144993fb5de044e2e8d900d7643b98a4d/mfbt/RefPtr.h#142



> On Tue, Oct 2, 2018 at 9:30 AM Andrew McCreight 
> wrote:
>
>> I've landed bug 1494765, which allows you to do assignments between
>> nsCOMPtrs for classes that are related by subtyping.
>>
>> For instance:
>>
>> class A { ... ];
>> class B : public A { ... };
>>
>> nsCOMPtr b = ...;
>> nsCOMPtr a = b; // this works now
>>
>> This is a step towards bug 1493226, which is going to statically ban
>> trivial do_QueryInterface calls like this:
>>
>> nsCOMPtr a2 = do_QueryInterface(b);
>> ___
>> 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: assignment between related nsCOMPtrs<> now works

[Kris Maglione]

On Tue, Oct 02, 2018 at 09:29:51AM -0700, Andrew McCreight wrote:

This is a step towards bug 1493226, which is going to statically ban
trivial do_QueryInterface calls like this:


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

Multi-browser web-platform-tests results dashboard

[James Graham]

https://wpt.fyi is a dashboard containing the results of the full 
web-platform-tests suite in multiple versions of current browsers.


The default view shows test results in the latest stable releases of 
desktop Firefox/Chrome/Edge/Safari. There are several alternative views 
that are likely to be of interest to gecko developers:


* The "label" url parameter can be used to change the browser channel. 
https://wpt.fyi/?label=experimental shows the latest test results in 
Firefox Nightly, Chrome Dev and latest Edge Insider / Safari TP. 
label=beta gives results for Chrome and Firefox betas.


* The diff parameter in combination with others can be used to construct 
a two-way comparison. For example 
https://wpt.fyi/results/?products=firefox[beta],firefox[stable]&aligned=true&diff 
shows Firefox beta vs stable, and 
https://wpt.fyi/results/?products=chrome[experimental],firefox[experimental]&aligned=true&diff 
shows a comparison between latest Firefox and Chrome. The diff 
comparison is currently lossy  as it shows the sum of changes, which can 
misrepresent the case where /different/ tests pass and fail across the 
two browsers; a solution to this is currently under development.


* The "Interoperability" view (link on the main page) is an attempt to 
show which platform features have good/poor interop, as defined by the 
fraction of tests that have the same result in multiple browsers.


UI to replace the current LBI ("location bar interface" :) is planned work.

If there are changes that you need to make wpt.fyi better meet your 
needs please speak to me or file a bug at 
https://github.com/web-platform-tests/wpt.fyi/issues


Thanks to our colleagues in the Chrome Platform Predictability team and 
their associates at Bocoup who did the bulk of the work to make the 
dashboard happen.


= (Possibly) FAQ =

How often are the results updated?

Experimental (i.e. nightly/dev) builds of Firefox and Chrome are run on 
Linux using Taskcluster after each commit to web-platform-tests. The 
test runs can be found on 
https://github.com/web-platform-tests/wpt/commits/master (click on the 
green tick). Beta builds are run weekly and stable builds daily. Safari 
and stable Edge are run on a buildbot instance hosted by Bocoup and are 
updated roughly daily (there are also buildbot runs of Firefox and 
Chrome stable). Edge insider results are provided by Microsoft, sometimes.


What browser settings are used?

For Firefox we apply the same profile settings we use for internal CI 
from testing/profiles (but not test-specific prefs set in 
testing/web-platform/meta). For stable/beta builds the prefs are taken 
from the user.js files in release/beta repositories. Note that this 
means that non-experimental builds are run with whatever prefs are 
enabled there. I'd like to clean this up so that beta/release more 
closely match released beta/release. Chrome uses 
--enable-experimental-web-platform-features for experimental builds and 
only prefs required for the test harness to run in other configurations. 
I believe that Edge and Safari are also run with minimal changes from 
the default pref set.


How are the tests run?

Tests are run using the `wpt run` command in the web-platform-tests 
repository. For example you can replicate the results from firefox beta 
running something like `wpt run --channel beta --install-browser firefox 
`. The docker image used for Taskcluster runs is in tools/docker/. 
The underlying harness is wptrunner which also used for Gecko CI.


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

Intent to ship: unprefixed max-content and min-content for css sizing properties

[Boris Chiou]

Summary:
`max-content` and `min-content` are sizing values for width, min-width,
max-width, height, min-height, max-height, inline-size, min-inline-size,
max-inline-size, and flex-basis. We support these two keywords with -moz-
prefix for many years, and Google Chrome has shipped them for 3 years. Our
implementation on inline-size dimension are stable, and it'd be nicer to
unprefix the keywords so people don't have to write both versions (i.e.
prefixed and unprefixed) on their websites. Therefore, I think it's worth
to unprefix them.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1322780


Link to standard: https://drafts.csswg.org/css-sizing/#sizing-values

Platform coverage: all platforms

Estimated or target release: Firefox 64

Do other browser engines implement this?
Chrome has shipped unprefixed max-content and min-content values from 46
[1]. Safari still uses -webkit- prefixed.

Preference behind which this will be implemented: n/a
DevTools bug: n/a

[1] https://caniuse.com/#feat=intrinsic-width

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

Re: Multi-browser web-platform-tests results dashboard

[Boris Zbarsky]

On 10/2/18 1:38 PM, James Graham wrote:
Experimental (i.e. nightly/dev) builds of Firefox and Chrome are run on 
Linux using Taskcluster after each commit to web-platform-tests.


Would a commit to Firefox that fixes some tests and just touches wpt 
.ini files to mark those tests as passing trigger such a run?  It sounds 
like it would not...


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