Re: WebRender on in Firefox Nightly for Windows 10 Nvidia

[Andreas Bovens]

Amazing news and a true milestone! Congrats to everyone who's been working
to make this happen! 

On Wed, 12 Sep 2018, 21:07 Jeff Muizelaar,  wrote:

> In bug 1490742 I have enabled WebRender in Nightly on non-laptop
> Windows 10 Nvidia (~17% of our Nightly audience). This is a rewrite of
> much the graphics backend in Firefox. We expect some edge-case
> regressions, but generally nothing serious. We have quite a few staff
> and volunteers who have been using WebRender for months without major
> issues.
>
> If you're on this hardware and you see a problem please file a bug.
> You can check if you're using WebRender by looking at the Compositing
> section of about:support. Further, WebRender should be generally
> usable on all platforms other than Android right now so if you want to
> be keen you can try it out now with the gfx.webrender.all pref.
>
> -Jeff
> ___
> 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: WebRender on in Firefox Nightly for Windows 10 Nvidia

[Marissa (Reese) Morris]

This is awesome!  Congrats!

 

Marissa (Reese) Morris | Cell Phone   303-506-3282 |  
 re...@mozilla.com | Slack: #Marissa (Reese)

 

From: firefox-dev  On Behalf Of Justin Dolske
Sent: Wednesday, September 12, 2018 2:43 PM
To: Mozilla ; firefox-dev 

Subject: Re: WebRender on in Firefox Nightly for Windows 10 Nvidia

 

\o/ Congrats on this major milestone! Exciting times for Firefox ahead! :D

 

Justin

 

On Wed, Sep 12, 2018 at 1:38 PM, Jean-Yves Avenard mailto:jyaven...@mozilla.com> > wrote:

What an achievement…

Congrats to you and the team….

JY


> On 12 Sep 2018, at 10:07 pm, Jeff Muizelaar   > wrote:
> 
> In bug 1490742 I have enabled WebRender in Nightly on non-laptop
> Windows 10 Nvidia (~17% of our Nightly audience). This is a rewrite of
> much the graphics backend in Firefox. We expect some edge-case
> regressions, but generally nothing serious. We have quite a few staff
> and volunteers who have been using WebRender for months without major
> issues.
> 
> If you're on this hardware and you see a problem please file a bug.
> You can check if you're using WebRender by looking at the Compositing
> section of about:support. Further, WebRender should be generally
> usable on all platforms other than Android right now so if you want to
> be keen you can try it out now with the gfx.webrender.all pref.
> 
> -Jeff
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org  
> https://lists.mozilla.org/listinfo/dev-platform


___
firefox-dev mailing list
firefox-...@mozilla.org  
https://mail.mozilla.org/listinfo/firefox-dev

 

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

Re: WebRender on in Firefox Nightly for Windows 10 Nvidia

[Justin Dolske]

\o/ Congrats on this major milestone! Exciting times for Firefox ahead! :D

Justin

On Wed, Sep 12, 2018 at 1:38 PM, Jean-Yves Avenard 
wrote:

> What an achievement…
>
> Congrats to you and the team….
>
> JY
>
> > On 12 Sep 2018, at 10:07 pm, Jeff Muizelaar 
> wrote:
> >
> > In bug 1490742 I have enabled WebRender in Nightly on non-laptop
> > Windows 10 Nvidia (~17% of our Nightly audience). This is a rewrite of
> > much the graphics backend in Firefox. We expect some edge-case
> > regressions, but generally nothing serious. We have quite a few staff
> > and volunteers who have been using WebRender for months without major
> > issues.
> >
> > If you're on this hardware and you see a problem please file a bug.
> > You can check if you're using WebRender by looking at the Compositing
> > section of about:support. Further, WebRender should be generally
> > usable on all platforms other than Android right now so if you want to
> > be keen you can try it out now with the gfx.webrender.all pref.
> >
> > -Jeff
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebRender on in Firefox Nightly for Windows 10 Nvidia

[Jean-Yves Avenard]

What an achievement…

Congrats to you and the team….

JY

> On 12 Sep 2018, at 10:07 pm, Jeff Muizelaar  wrote:
> 
> In bug 1490742 I have enabled WebRender in Nightly on non-laptop
> Windows 10 Nvidia (~17% of our Nightly audience). This is a rewrite of
> much the graphics backend in Firefox. We expect some edge-case
> regressions, but generally nothing serious. We have quite a few staff
> and volunteers who have been using WebRender for months without major
> issues.
> 
> If you're on this hardware and you see a problem please file a bug.
> You can check if you're using WebRender by looking at the Compositing
> section of about:support. Further, WebRender should be generally
> usable on all platforms other than Android right now so if you want to
> be keen you can try it out now with the gfx.webrender.all pref.
> 
> -Jeff
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform



smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

WebRender on in Firefox Nightly for Windows 10 Nvidia

[Jeff Muizelaar]

In bug 1490742 I have enabled WebRender in Nightly on non-laptop
Windows 10 Nvidia (~17% of our Nightly audience). This is a rewrite of
much the graphics backend in Firefox. We expect some edge-case
regressions, but generally nothing serious. We have quite a few staff
and volunteers who have been using WebRender for months without major
issues.

If you're on this hardware and you see a problem please file a bug.
You can check if you're using WebRender by looking at the Compositing
section of about:support. Further, WebRender should be generally
usable on all platforms other than Android right now so if you want to
be keen you can try it out now with the gfx.webrender.all pref.

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

Re: MinGW Target Re-Enabled on TaskCluster

[Kris Maglione]

Thank you. This will make my development flow much easier.

On Wed, Sep 12, 2018 at 12:09:36AM -0500, Tom Ritter wrote:

Previous Thread:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/r3mYWbb42pM

As of a few hours ago, there is a new Tier 2 MinGW build on TaskCluster.
It's in the 'Windows MinGW all' line, with the group WMC64 for 'Windows
MinGW Clang x64'.


The MinGW builds are part of the Tor Uplift project, where we work closely
with Tor to upstream their patches and in general move Tor Browser closer
and closer to 'Firefox with Addons and Pref Changes' - instead of a fork of
Firefox with a bunch of custom patches.

Tor is currently using ESR releases: the bump to ESR60 (which occurred last
week! It's a huge release for them with a lot of UX improvements:
https://blog.torproject.org/new-release-tor-browser-80 ) was a lot smoother
- build-wise - than other bumps because we had the MinGW build running in
TC. Without keeping the MinGW build working, every ESR they have to go
through a potentially colossal amount of work on a short timescale to get
the build working under MinGW again. By minimizing their effort in fixing
the build, rebasing patches and the like - we can free up their limited
resources to continue to research and experiment on privacy technology like
First Party Isolation and Fingerprinting Resistance.



Now, you might be wondering "I thought we had a MinGW build?" We did. But
we had to disable it. Shortly after 60 went to beta, we removed support for
--disable-stylo. Stylo requires libclang to build; and getting that working
with MinGW was very complicated (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1390583) so MinGW fell behind
and had to be disabled.

However, thanks (again) to the efforts of all the reviewers, build peers,
and especially Jacek Caban - we've been able to re-enable a MinGW build.
We are now building with clang using the MinGW headers. (Previously it was
gcc.) I believe we're the first 'real' project that is building with
MinGW-clang, and Tor will be the first major project to ship it (but I
could be wrong there.)

In configure and moz.build files, CC_TYPE will be 'clang-cl' for our normal
Windows builds (which build on Windows) and will be 'clang' for the
MinGW-clang builds (which build on Linux).

There are still some outstanding issues: I hope to land a x86 build, we
need to remove some of the --disable-foo flags, and once ESR60 gets a NSS
uplift I intend the backport the jobs there also. We hope to get pdbs
generating so we can debug easier - major appreciation to David Major and
Bob Owen who both have debugged pretty ugly crashes without symbols.
Eventually, I'd like to enable a limited set of tests to catch browser
crashes.  Because there is no path forward for getting the MinGW gcc builds
re-enabled (nor anyone who wants to work on it...) I intend to remove the
(disabled) build jobs from the tree also. And finally I need to document
how to get a local build environment for it.


MinGW is Tier 2, and sometimes breaking it is unavoidable because the fix
needs to happen upstream in MinGW. Other times breaking it is avoidable,
and one just needs to special-case it. The Tor Uplift team and Tor
themselves greatly appreciate all of your efforts to keep the build green.

As always, if you have a MinGW question or a build error you can't quite
understand - feel free to reach out to me via irc or email.


--

It is practically impossible to teach good programming style to
students that have had prior exposure to Basic; as potential
programmers they are mentally mutilated beyond hope of regeneration.
--Edsger W. Dijkstra

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

Re: geckodriver enabled in local developer builds

[Bobby Holley]

Thanks for doing this! I recently struggled to run some tests before
realizing that they depended on geckodriver, which wasn't built by default.
Assuming this didn't negatively impact build times, I'm glad to see a
reduction in build config options.

On Wed, Sep 12, 2018 at 2:36 AM Andreas Tolfsen  wrote:

> We have been building geckodriver on TaskCluster for a year and a
> half, but it has so far not been enabled by default in local developer
> builds.
>
> With a change that landed yesterday, geckodriver is included in the
> default build configuration also for local developer builds.  It
> will not be built if --disable-tests is used.  You can also explicitly
> disable building it with --disable-geckodriver.
>
> geckodriver is our implementation of WebDriver, and in m-c, used
> to back a subset of WPT tests.  It is also a product in its own
> right, in that it is used by several major websites that we care
> about to help web compatibility.  As we roll out support for more
> platforms we expect to expand its in-tree use.
> ___
> 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: Changes to BMO-Phabricator integration

[Ehsan Akhgari]

Hi everyone,

As someone who cares a lot about code review (both as a developer and as a
reviewer), I care a lot about the tools I work with and the workflows I’ve
built around them over the years.  I’m sure I’m not the only one there.

What Mark wrote about below brings changes to some parts of our code review
workflows and I think it’s fair to assume that some people will find the
change unpleasant.  I think it’s important to know that decisions like this
aren’t made lightly though, and the team working on Phabricator has looked
into making this integration work as much as possible, before coming to
this final conclusion.

What I’ve learned from the experience of the folks who worked closely on
this project over the past 3-4 years is that integrating an existing code
review system with an existing issue management system is an extremely
difficult task.  There are certainly huge benefits to be reaped if a tight
integration is achieved, but there are great costs to also consider, and
the trade-off is tricky to get right.

As much as deep down in my heart, I secretly wish nothing would ever change
so that I could hold on to my old habits until who-knows-when, I realize
that sometimes it’s prudent to do what’s hard -- shaking off old habits and
workflows and pick up new ones, in the interest of the greater good.

In this case, even with my reviewer hat on, I think it would certainly be a
mistake for us to have tried as hard as we did for MozReview to integrate
BMO and Phabricator together at the expense of holding back the deployment
of Phabricator and new features in it.  If our smart engineers working on
this hard problem have looked at this integration issue, have tried to make
it work, and have decided down the line that it’s best to correct course,
my hunch is to trust them and consider maybe it’s time to change some of my
old habits on how I interact with code reviews on Bugzilla.

Thanks,
Ehsan

On Wed, Sep 12, 2018 at 10:37 AM Mark Côté  wrote:

> To reduce confusion and a growing maintenance burden, the Engineering
> Workflow team plans to remove two pieces of Phabricator-Bugzilla
> integration:
>
>
>1.
>
>The setting of r+ flags on the stub attachments in that link to
>Phabricator revisions (
>https://bugzilla.mozilla.org/show_bug.cgi?id=1490687).
>2.
>
>The Phabricator table in Bugzilla’s “My Requests” page (
>https://bugzilla.mozilla.org/show_bug.cgi?id=1487422).
>
>
> We plan on adding one more piece of integration: a panel on bug views
> (show_bug.cgi) that shows the status of Phabricator revisions in
> Phabricator’s terms, similar to the old MozReview table (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1489706).
>
> The “stub attachments” will remain for the time being in order to
> facilitate tracking non-review attachment flags (checkin-needed, etc).
>
> # Rationale and background
>
> There have been a lot of questions about our decisions surrounding
> Bugzilla–Phabricator integration. We’ve expounded on those in various
> threads over the last year and a half, but I will try to go into more
> specifics.
>
> At the start of the Phabricator project, having learned a lot from
> MozReview, we consciously decided to limit the amount of integration to
> Bugzilla. This not only reduces upfront costs and maintenance burden but
> also avoids the complexity and ambiguity inherent in mixing two different
> systems together. Aside from necessary linkages like authentication,
> accounts, and security groups, the only other integration we implemented
> was the setting of r+ statuses on stub attachments and, later, adding
> Phabricator requests to BMO’s “My Dashboard”.
>
> Unfortunately both of these have had bugs and caused confusion. Since
> comments aren’t mirrored, the plain r+s were sometimes misleading if the
> revisions (or Phabricator’s email notifications) weren’t also consulted
> before landing. The requests view on “My Dashboard” suffered from bugs that
> resulted in missing requests and was further impacted by our experiments
> with reviewer groups that have no real analog in Bugzilla.
>
> # Differing models
>
> The central problem is that the models behind the two systems—Bugzilla’s
> attachments and flags, Phabricator’s revisions and reviews—are very
> different. Phabricator’s revisions have a much richer and more complex set
> of metadata than Bugzilla attachments. It is essentially impossible to
> represent Phabricator states as Bugzilla flags while preserving anything
> close to the expected semantics of the latter; consulting Phabricator would
> often be needed to make sense of any translated representation in Bugzilla.
> Further, Phabricator’s model is also subject to changes and additions (for
> example, the draft revision state, which is still being modified), which
> creates additional fragility and maintenance burden. Finally, not all the
> details we need are even exposed through APIs, in part because they are in
> flux.
>
> # Adding revision 

Changes to BMO-Phabricator integration

[Mark Côté]

To reduce confusion and a growing maintenance burden, the Engineering
Workflow team plans to remove two pieces of Phabricator-Bugzilla
integration:


   1.

   The setting of r+ flags on the stub attachments in that link to
   Phabricator revisions (
   https://bugzilla.mozilla.org/show_bug.cgi?id=1490687).
   2.

   The Phabricator table in Bugzilla’s “My Requests” page (
   https://bugzilla.mozilla.org/show_bug.cgi?id=1487422).


We plan on adding one more piece of integration: a panel on bug views
(show_bug.cgi) that shows the status of Phabricator revisions in
Phabricator’s terms, similar to the old MozReview table (
https://bugzilla.mozilla.org/show_bug.cgi?id=1489706).

The “stub attachments” will remain for the time being in order to
facilitate tracking non-review attachment flags (checkin-needed, etc).

# Rationale and background

There have been a lot of questions about our decisions surrounding
Bugzilla–Phabricator integration. We’ve expounded on those in various
threads over the last year and a half, but I will try to go into more
specifics.

At the start of the Phabricator project, having learned a lot from
MozReview, we consciously decided to limit the amount of integration to
Bugzilla. This not only reduces upfront costs and maintenance burden but
also avoids the complexity and ambiguity inherent in mixing two different
systems together. Aside from necessary linkages like authentication,
accounts, and security groups, the only other integration we implemented
was the setting of r+ statuses on stub attachments and, later, adding
Phabricator requests to BMO’s “My Dashboard”.

Unfortunately both of these have had bugs and caused confusion. Since
comments aren’t mirrored, the plain r+s were sometimes misleading if the
revisions (or Phabricator’s email notifications) weren’t also consulted
before landing. The requests view on “My Dashboard” suffered from bugs that
resulted in missing requests and was further impacted by our experiments
with reviewer groups that have no real analog in Bugzilla.

# Differing models

The central problem is that the models behind the two systems—Bugzilla’s
attachments and flags, Phabricator’s revisions and reviews—are very
different. Phabricator’s revisions have a much richer and more complex set
of metadata than Bugzilla attachments. It is essentially impossible to
represent Phabricator states as Bugzilla flags while preserving anything
close to the expected semantics of the latter; consulting Phabricator would
often be needed to make sense of any translated representation in Bugzilla.
Further, Phabricator’s model is also subject to changes and additions (for
example, the draft revision state, which is still being modified), which
creates additional fragility and maintenance burden. Finally, not all the
details we need are even exposed through APIs, in part because they are in
flux.

# Adding revision statuses to bugs

That said, we realize that seeing at a glance the state of revisions
associated with a given bug is very useful. We are building support into
Bugzilla to view revision data without translation into Bugzilla’s terms to
avoid any confusion as to the true state of revisions.

While we could also dump data from Phabricator’s dashboard into Bugzilla’s
“My Dashboard”, it would be much more work and more difficult to maintain,
since Phabricator’s dashboard itself is being updated. Furthermore, as all
code reviews are transitioned to Phabricator, the importance of this
dashboard will grow, and the number of requests in Bugzilla will shrink.
Thus relying on Phabricator to do what it does best is the better solution
for the future.

# Acknowledging difficulties

We are aware that splitting code review out into a separate system is a
huge change. We realize that, with our new tools and the decisions we have
made around integration, we are asking you to change your workflows by
setting up different email rules, looking in different places for the data
you need, communicating with other Mozillians in different ways, and
perhaps even establishing new practices and norms around code review. It
will take time to adapt. However we are already seeing benefits in terms of
automation that we haven’t previously been able to do (just one example: a
user set up Herald rules to notify of changes that impact localization),
and we will continue to build on this framework to accomplish goals that
have been talked about for many years. Allowing the tools to do what they
are best at lets us focus on new functionality, including suggested
reviewers, Try support for Lando, Lando notifications, fully automated
landings, and other items on our road map (
https://wiki.mozilla.org/Engineering_Workflow/Road_Map).

We appreciate your feedback and support as we work to improve the tools you
use every day.

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

Re: Intent to Implement: Storage Access API

[Ehsan Akhgari]

On Wed, Sep 12, 2018 at 3:47 AM Anne van Kesteren  wrote:

> On Tue, Sep 11, 2018 at 9:06 PM Ehsan Akhgari 
> wrote:
> > Please note that Firefox will grant storage access permissions
> > automatically under certain circumstances for web compatibility reasons,
> so
> > even when the iframe has never called this API it may still obtain
> storage
> > access.  In order to prevent that from happening, the usual approaches
> > against embedded content gaining storage access (through sandboxing the
> > iframe to give it a unique origin) could be used.
>
> Unfortunately, that will still share cookies. Adding a feature policy
> or some such for that might be worthwhile.
>

Yes indeed.  But that's beyond the scope of the current intent thread.

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

Re: MinGW Target Re-Enabled on TaskCluster

[Tom Ritter]

On Wed, Sep 12, 2018 at 12:09 AM, Tom Ritter  wrote:

> However, thanks (again) to the efforts of all the reviewers, build peers,
> and especially Jacek Caban - we've been able to re-enable a MinGW build.
> We are now building with clang using the MinGW headers. (Previously it was
> gcc.) I believe we're the first 'real' project that is building with
> MinGW-clang, and Tor will be the first major project to ship it (but I
> could be wrong there.)
>

I forgot to add a couple of really big thanks that are large enough to
prompt a followup-email: Georg did a lot of the initial Stylo build
investigation; and Martin Storsjö also helped on Stylo and was either the
creator of the mingw-clang toolchain or has worked on it enough and done
enough fixes to it that I thought he was.

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

Re: MinGW Target Re-Enabled on TaskCluster

[Ted Mielczarek]

On Wed, Sep 12, 2018, at 1:09 AM, Tom Ritter wrote:
> Previous Thread:
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/r3mYWbb42pM
> 
> As of a few hours ago, there is a new Tier 2 MinGW build on TaskCluster.
> It's in the 'Windows MinGW all' line, with the group WMC64 for 'Windows
> MinGW Clang x64'.
> 
> 
> The MinGW builds are part of the Tor Uplift project, where we work closely
> with Tor to upstream their patches and in general move Tor Browser closer
> and closer to 'Firefox with Addons and Pref Changes' - instead of a fork of
> Firefox with a bunch of custom patches.

Big thanks to Tom and everyone else that helped for doing all of this hard work 
twice: once to stand up the initial mingw build, and again after we broke that 
one by requiring stylo. The work that the Tor project does is incredibly 
important, and making it easier for them to ship Tor Browser by not having to 
spend a bunch of time fixing all the things we broke upstream should have a 
huge impact.

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

geckodriver enabled in local developer builds

[Andreas Tolfsen]

We have been building geckodriver on TaskCluster for a year and a
half, but it has so far not been enabled by default in local developer
builds.

With a change that landed yesterday, geckodriver is included in the
default build configuration also for local developer builds.  It
will not be built if --disable-tests is used.  You can also explicitly
disable building it with --disable-geckodriver.

geckodriver is our implementation of WebDriver, and in m-c, used
to back a subset of WPT tests.  It is also a product in its own
right, in that it is used by several major websites that we care
about to help web compatibility.  As we roll out support for more
platforms we expect to expand its in-tree use.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MinGW Target Re-Enabled on TaskCluster

[Georg Koppen]

Tom Ritter:
> Previous Thread:
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/r3mYWbb42pM
> 
> As of a few hours ago, there is a new Tier 2 MinGW build on TaskCluster.
> It's in the 'Windows MinGW all' line, with the group WMC64 for 'Windows
> MinGW Clang x64'.
>

Yay, thanks so much for that. I am pretty sure it will help us saving a
ton of work once we plan to switch to the mingw-w64/clang toolchain, as
your work on integrating the mingw-w64/gcc toolchain into TaskCluster
already did.

> 
> The MinGW builds are part of the Tor Uplift project, where we work closely
> with Tor to upstream their patches and in general move Tor Browser closer
> and closer to 'Firefox with Addons and Pref Changes' - instead of a fork of
> Firefox with a bunch of custom patches.
> 
> Tor is currently using ESR releases: the bump to ESR60 (which occurred last
> week! It's a huge release for them with a lot of UX improvements:
> https://blog.torproject.org/new-release-tor-browser-80 ) was a lot smoother
> - build-wise - than other bumps because we had the MinGW build running in
> TC. Without keeping the MinGW build working, every ESR they have to go
> through a potentially colossal amount of work on a short timescale to get
> the build working under MinGW again. By minimizing their effort in fixing
> the build, rebasing patches and the like - we can free up their limited
> resources to continue to research and experiment on privacy technology like
> First Party Isolation and Fingerprinting Resistance.

Let me jump in here as the one responsible for coordinating our efforts
to switch Tor Browser to ESR 60, and the one working on the
mingw-w64-based toolchain upgrades in the past. Having to deal with the
mingw-w64 upgrade for a new ESR has been one of the top three pain
points in previous years.

I usually started weeks before we began with the "official" transition
part, to estimate how much is broken and how complex fixes would be by
bisecting and filing bugs at bugzilla. Thanks to the help of Jacek Caban
we always had the toolchain ready before we needed to switch, but it was
pretty close sometimes. All this work has essentially not been needed
anymore this time, thanks to the effort of Tom and others, and we are
very grateful for that.

Given that background I am more than happy to see the results of the
continued work in that direction with the arrival of the
mingw-w64/clang-based Windows build on Taskcluster.

Thanks Mozilla and thanks to those engineers in particular who helped
(and still help) with that effort.

Georg



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

PSA: All nightlies for tier-1 platforms are now built with clang and at least LTO

[Mike Hommey]

Hi,

As per the subject, as of next nightly, Windows, Mac, Linux, and Android
nightlies are now all built with clang, with LTO enabled for all of them,
and also with PGO for Windows and Linux.

More about it on https://glandium.org/blog/?p=3888

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

Re: Intent to Implement: Storage Access API

[Anne van Kesteren]

On Tue, Sep 11, 2018 at 9:06 PM Ehsan Akhgari  wrote:
> Please note that Firefox will grant storage access permissions
> automatically under certain circumstances for web compatibility reasons, so
> even when the iframe has never called this API it may still obtain storage
> access.  In order to prevent that from happening, the usual approaches
> against embedded content gaining storage access (through sandboxing the
> iframe to give it a unique origin) could be used.

Unfortunately, that will still share cookies. Adding a feature policy
or some such for that might be worthwhile.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform