Status of Ubuntu 20.04 as a development platform
Does Ubuntu 20.04 work properly as a platform for Firefox development? That is, does rr work with the provided kernel and do our tools work with the provided Python versions? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 84 starts November 12
Hi all, With Firefox 83 RC shipping soon, we are nearing the end of the Nightly 84 cycle. In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out Beta 84 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from Thursday November 12 until after the version bump to 85 on November 16. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Pascal & the Release Management team -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management https://fx-trains.herokuapp.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Status of Ubuntu 20.04 as a development platform
On Tue, Nov 10, 2020 at 3:48 AM Henri Sivonen wrote: > > Does Ubuntu 20.04 work properly as a platform for Firefox development? > That is, does rr work with the provided kernel and do our tools work > with the provided Python versions? rr works. I use 20.04 personally. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Status of Ubuntu 20.04 as a development platform
On 10/11/2020 14:17, Kyle Huey wrote: On Tue, Nov 10, 2020 at 3:48 AM Henri Sivonen wrote: Does Ubuntu 20.04 work properly as a platform for Firefox development? That is, does rr work with the provided kernel and do our tools work with the provided Python versions? rr works. I use 20.04 personally. I've also been using 20.04 and all the Python bits have worked fine. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Status of Ubuntu 20.04 as a development platform
Just updated to 20.10 (not 20.04) last week and things work fine here. (I have not tested rr yet) Am 10.11.20 um 15:39 schrieb James Graham: > On 10/11/2020 14:17, Kyle Huey wrote: >> On Tue, Nov 10, 2020 at 3:48 AM Henri Sivonen >> wrote: >>> >>> Does Ubuntu 20.04 work properly as a platform for Firefox development? >>> That is, does rr work with the provided kernel and do our tools work >>> with the provided Python versions? >> >> rr works. I use 20.04 personally. > > I've also been using 20.04 and all the Python bits have worked fine. > ___ > 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: Status of Ubuntu 20.04 as a development platform
On 11/10/20 12:48 PM, Henri Sivonen wrote: Does Ubuntu 20.04 work properly as a platform for Firefox development? That is, does rr work with the provided kernel and do our tools work with the provided Python versions? It would be great to have Ubuntu 20.04 option in try to test Firefox Wayland backend on it. -- Martin Stransky Software Engineer / Red Hat, Inc ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Prototype: PerformanceEventTiming API
Summary: PerformanceEventTiming API provides web page authors with insights into the latency of certain events triggered by user interactions. This is prerequisite for Web Vital. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1667836 Standard: https://wicg.github.io/event-timing/#sec-performance-event-timing Platform coverage: All Platforms Preference: dom.enable_event_timing DevTools bug: N/A Other browsers: - Chrome: Enabled by default since 85. - Safari: Not implemented web-platform-tests: https://github.com/web-platform-tests/wpt/tree/master/event-timing ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Remove: Fuzzyfox
Fuzzyfox[0] is an implementation of a research idea that severely limits the data that can be extracted by timing side channels exploited by untrusted JavaScript. It effectively provides a knob that allows one to control the amount of data that can be extracted by controlling the coarseness and fuzziness of the clock used by the browser. In comparison to our existing clock fuzziness enabled now, it operates in the context of the entire browser, rather than just the explicit timers and clocks exposed to untrusted JavaScript - therefore it also mitigates the data that can be extracted by constructed clocks relying on e.g. web animations. Unfortunately it does not address the fact that Shared Array Buffer can be turned into a precise timer, it was written in the early days of SAB and produces its results by disabling it. We landed it two years ago[1], and had intended to explore it further if needed for Spectre, as well as see if it could be used practically to mitigate the multiple and various timing attacks that have been demonstrated in browsers to steal user browser history, cross-application user activity, cross-origin images or frame data, etc etc. We've never gotten to that examination, and it seems that we might never; so in the interest of clarity and cleanliness it makes sense to remove it. Presently, if you enable privacy.fuzzyfox.enabled you will switch over to Fuzzyfox mode. You will probably experience some jank and bowser slowdown. Fuzzyfox affects the entire browser, and that does include sleeping on the main thread[2] in certain circumstances. Had time been available, the next steps would have been to get profiles of poor browser behavior under Fuzzyfox, and try to understand why they were occuring. (Setting privacy.fuzzyfox.clockgrainus too coarse would cause expected slowness, but 250 ought to be a usable number, ideally 1000.) This work will be done in https://bugzilla.mozilla.org/show_bug.cgi?id=1666222 -tom [0] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kohlbrenner [1] https://bugzilla.mozilla.org/show_bug.cgi?id=fuzzyfox [2] https://searchfox.org/mozilla-central/rev/02cb78667e87ccc42fea5edc6f3f2dd2edd6ecd5/toolkit/components/fuzzyfox/Fuzzyfox.cpp#212-216 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
