PSA: Firefox Nightly now with experimental Wayland support
Hi, As of last nightly (20181115100051), Firefox now supports Wayland, thanks to the work from Martin Stransky and Jan Horak, mostly. Before that, it was possible to build your own Firefox with Wayland support (and Fedora does it), but now the downloads from mozilla.org come with Wayland support out of the box for the first time. However, being experimental and all, the Wayland support is not enabled by default, meaning by default, you'll still be using XWayland. To enable wayland support, first set the `GDK_BACKEND` environment variable to `wayland`. To verify whether Wayland support is enabled, go to `about:support`, and check "WebGL 1 Driver WSI Info" and/or "WebGL 2 Driver WSI Info". If they say something about `GLX`, Wayland support is not enabled. If they say something about `EGL`, it is. I filed a bug[1] to make it more obvious what is being used. It's probably still a long way before Firefox enables Wayland support on Wayland by default, but we reached a major milestone here. Please test and report any bug you encounter[2]. Mike 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1507665 2. https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Widget%3A%20Gtk ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: Web Fonts Working Group
The W3C is proposing a revised charter for: Web Fonts Working Group https://www.w3.org/Fonts/WG/webfonts-2018-ac.html https://lists.w3.org/Archives/Public/public-new-work/2018Oct/0015.html This is proposing a new work item for the group, Progressive Font Enrichment, to allow progressive download of subsets of the font's glyph repetoire. Mozilla has the opportunity to send comments or objections through next Tuesday, November 20. Please reply to this thread if you think there's something we should say as part of this charter review, or if you think we should support or oppose it. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
There is a proposal to support "report-only" violations for feature policy: https://github.com/WICG/feature-policy/blob/824de86f89599240c24b5ae3cd58d25984446af5/reporting.md I think we should implement this API for these reasons: a. it unifies the reporting of violations and interventions. At the moment we have FeaturePolicy, Interventions, crashes and deprecated APIs, but it's easy to imagine reports coming from CSP violations, CORB, Origin-policy etc. b. Often, when an intervention is made, the only thing a browser does is to write a message in the console. autoplay heuristic and tracking protection are just 2 examples. Here we can do something more: we can communicate something to the page, using ReportingObserver. c. it's a nice diagnostic tool for websites. In the 'report-to' HTTP header, entry-points can be used as communication channel between the browser and the server. On Thu, Nov 15, 2018 at 5:25 PM Boris Zbarsky wrote: > On 11/15/18 9:52 AM, Ehsan Akhgari wrote: > > The idea is to use Feature Policy in report-only mode > > There is no report-only mode in the Feature Policy spec, nor in our > implementation. See the note at the end of > https://wicg.github.io/feature-policy/#reporting > > So I'm back to my question: is this an API we actually want to > implement? It seems like a fair amount of complexity and overhead and > the one use case so far is for sites to have telemetry for when they're > ending up with feature policy violations, right? > > -Boris > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On 11/15/18 9:52 AM, Ehsan Akhgari wrote: The idea is to use Feature Policy in report-only mode There is no report-only mode in the Feature Policy spec, nor in our implementation. See the note at the end of https://wicg.github.io/feature-policy/#reporting So I'm back to my question: is this an API we actually want to implement? It seems like a fair amount of complexity and overhead and the one use case so far is for sites to have telemetry for when they're ending up with feature policy violations, right? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On Wed, Nov 14, 2018 at 11:20 AM Boris Zbarsky wrote: > On 11/13/18 4:33 AM, Andrea Marchesini wrote: > > I decided to implement this API, because it is required in the > > web-platform-tests for FeaturePolicy. > > Is it needed for any other reason? If not, this seems like a bug in the > tests: they should not be coupling the two specs together. > It is. The Reporting API and Feature Policy are meant to be used together. For example, developers may want to reduce the usage of sync XHR on their website, but on a very complex site it may not be easy to figure out where sync XHR is being used. The idea is to use Feature Policy in report-only mode to report the usages of Sync XHR for example so that they can fix them gradually without disallowing Sync XHR using Feature Policy right off the bat. -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
