Re: New and improved stack-fixing
Thank you for the work you put in making this happen! I for one certainly appreciate the results - stack symbolication used to be pretty dodgy for me but now it seems fast and reliable! On Tue, Apr 14, 2020 at 10:22 PM Nicholas Nethercote wrote: > > On Fri, 6 Mar 2020 at 09:52, Nicholas Nethercote > wrote: >> >> >> I have written a new stack-fixing tool, called `fix-stacks`, which >> symbolizes stack traces produced by Firefox. >> >> [...] >> >> There is more work to be done. Soon, I plan to: >> >> * use `fix-stacks` on test outputs (in `utils.py` and `automation.py.in`); >> >> * re-enable stack fixing on Mac test runs on local builds, which is >> currently disabled because it is so slow; >> >> * add breakpad symbol support to `fix-stacks`; >> >> * remove the old scripts. > > > I have done these four things now. There has been a long tail of issues to > work through relating to test output on automation, and there may still be > problems with obscure build or test jobs or intermittent failures. If you see > any problems where `fix-stacks` is mentioned, please let me know. > > For those of you who are interested in a detailed description of this work, > please take a look at > https://blog.mozilla.org/nnethercote/2020/04/15/better-stack-fixing-for-firefox/. > > Nick > ___ > 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
Remote Canvas 2D has been re-enabled on Nightly
Hi all, The latest Nightly has the pref re-enabled to move accelerated Canvas 2D to the GPU process on Windows. This is only enabled on Nightly at the moment and is part of our work to move GPU access and win32k system calls out of the content process. Please file any problems you find as bugs blocking: https://bugzilla.mozilla.org/show_bug.cgi?id=1548487 Thanks, Bob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: AudioWorklet
As of this week I intend to turn on AudioWorklet by default for all platforms. It has been developed behind the "dom.audioworklet.enabled" and "dom.worklet.enabled" preferences. Status in other browsers is: Chrome, Opera: shipping. Edge, Webkit: not shipping, intentions unknown. Product: Adam Stevenson Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1616725 This feature was previously discussed in this "Intent to implement" thread: https://groups.google.com/forum/#!msg/mozilla.dev.platform/EtjfqRd9FI0/30DfQ3c6DgAJ =Target release This feature was enabled by default on Nightly from the 20200331093527 build. Nightly is now 77, but there is demand for this feature including some WFH benefits from one service provider, and so we are looking to uplift the pref switch to 76. =AudioNode lifetime interoperability The issue mentioned in the intent to implement post regarding observability of garbage collection through [AudioNode lifetimes] and interoperability with Chrome has been satisfactorily resolved by hiding the observability of AudioNode lifetimes. Chrome has modified their implementation in line with this resolution. =import Gecko's AudioWorklet implementation does not yet include support for static import of nested scripts. The lack of support shows up as rejection of the promise returned from Worklet#addModule(). (Worklets simply do not support dynamic import.) =Stability The specification is expected to be stable except for the nature of [parameters] passed to the client process() callback. The `inputs` and `outputs` parameters each have a `length` attribute and an indexed property getter, and the `parameters` parameter has a named property getter. This much is stable. There is ongoing discussion regarding whether the underlying JS Objects are frozen and whether Float32Array property values can be transferred via MessagePort#postMessage(). [AudioNode lifetimes] https://github.com/WebAudio/web-audio-api/issues/1471 [parameters] https://github.com/WebAudio/web-audio-api/issues/1933 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform