Intent to ship: Pointer Events (Desktop)

We had enabled Pointer Events on the nightly builds for a while and resolved the major blockers to ship it. Although there are some bugs ongoing and some spec issues under discussion, we think they don't block the functionalities of Pointer Events and plan to ship it within the next few weeks.

Browser Architecture Newsletter 4

Welcome to the fourth Browser Architecture Newsletter! A lot of the issues that the Browser Architecture team are digging into are larger than our team. Our goal is to discuss and review entire product level architecture issues and build consensus around solutions. We’re interested in engaging

Re: Change: Performance bugs handling and triaging

On Thu, Oct 19, 2017 at 03:40:53PM -0400, Boris Zbarsky wrote: Naveed, Thank you for continuing work on performance! New profiles that require analysis should be assigned to relevant domain experts. Do we have a plan for _generating_ profiles, or at least incentivizing generation thereof?

Re: Change: Performance bugs handling and triaging

Hey! Let me start by saying that to me Quantum Flow felt like hugely important work that made an immediate impact on how people perceive Firefox performance. I am really excited that we are going to continue working on this. You often hear people complaining about performance on YouTube and

Re: We need better canaries for JS code

On Thu, Oct 19, 2017, at 03:19 PM, Mark Banner wrote: > The only thing that might help (that has been discussed) is something > along the lines of flow - an analyser that could work out that 'spice()' > didn't exist, but Dave Townsend mentioned these don't seem to be viable > for us. > >

Re: Change: Performance bugs handling and triaging

Naveed, Thank you for continuing work on performance! New profiles that require analysis should be assigned to relevant domain experts. Do we have a plan for _generating_ profiles, or at least incentivizing generation thereof? This is a large part of what the Quantum Flow effort was

Re: We need better canaries for JS code

On 19/10/2017 14:02, Ted Mielczarek wrote: On Wed, Oct 18, 2017, at 07:51 AM, Mark Banner wrote: Looping in firefox-dev as well, as I thin this is an important discussion. On 18/10/2017 09:28, David Teller wrote: Hi everyone, Yesterday, Nightly was broken on Linux and MacOS

Re: We need better canaries for JS code

Dave, how would you feel about deciding on one of those and allowing modules to opt-in to using them, perhaps just as an experiment. Presumably most existing modules wouldn't, but new ones being written might. Dan 2017-10-18 9:06 GMT-07:00 Dave Townsend : > On Wed, Oct

Re: We need better canaries for JS code

Could we do this on a per-module opt-in basis to allow for gradual migration? That is to say, assuming there's enough information in the stack to tell where it was thrown from (I'm guessing that's the case most of the time), by default, ignore these errors unless they're from code in an opted-in

Re: Reviews for in-tree documentation

Dustin Mitchell 2017 October 19 at 10:21 I think we should question the assumption that writing source-code-level documentation is a good activity for newcomers to the codebase. Documentation is usually best written by someone with a deep understanding of what is

Re: Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

>SGTM. BTW, bug 143038 was filed 16 years ago. Is that a bugzilla record for >oldest fixed bug? Not even close I think... a couple of years ago I remember some low-4-digit bugs getting fixed (maybe even a 3-digit?) :-) -- Randell Jesup, Mozilla Corp remove "news" for personal email

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

On Thu, Oct 19, 2017 at 6:48 PM, Daniel Veditz wrote: > On Thu, Oct 19, 2017 at 9:30 AM, smaug wrote: > > > (Hoping the r=documentation flag won't be misused ;)) > > > ​I hope there will be some kind of hook making sure files touched in that > manner are

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

I think we should question the assumption that writing source-code-level documentation is a good activity for newcomers to the codebase. Documentation is usually best written by someone with a deep understanding of what is being documented, not by someone new to the project. And this

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

Also sprach Sylvestre Ledru: By the way, do we know how many mdn contributions are made on these pages by people who are not regular Firefox developers? A push in-tree requires permissions, which isn't a small barrier, might impact that (not mentioning the size of the repo). If this is only a

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

On Thu, Oct 19, 2017 at 9:30 AM, smaug wrote: > (Hoping the r=documentation flag won't be misused ;)) ​I hope there will be some kind of hook making sure files touched in that manner are all actually documentation files and not other parts of the repo. - ​Dan Veditz​

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

By the way, do we know how many mdn contributions are made on these pages by people who are not regular Firefox developers? A push in-tree requires permissions, which isn't a small barrier, might impact that (not mentioning the size of the repo). If this is only a few people, this might not be an

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

Sounds very reasonable. (Hoping the r=documentation flag won't be misused ;)) On 10/19/2017 04:37 PM, Andreas Tolfsen wrote: Some time ago there was a discussion on dev-builds@ regarding the state of our in-tree source code documentation. The main focus was that MDN, moving forward, will

Change: Performance bugs handling and triaging

Hello All, The weekly Quantum Flow performance triaging work has concluded with Firefox 57’s uplift to beta. We are no longer triaging bugs marked with the [qf] and [qf:p*] whiteboard tags. New performance bugs should be assigned to the appropriate component teams and will be addressed by their

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

On Thu, Oct 19, 2017 at 5:37 PM, Andreas Tolfsen wrote: > Some time ago there was a discussion on dev-builds@ regarding > the state of our in-tree source code documentation. The main > focus was that MDN, moving forward, will mainly revolve around web > platform documentation and

Reviews for in-tree documentation (was: Builds docs on MDN)

Some time ago there was a discussion on dev-builds@ regarding the state of our in-tree source code documentation. The main focus was that MDN, moving forward, will mainly revolve around web platform documentation and would actively start de-emphasising Gecko contribution docs. Now, that

Re: We need better canaries for JS code

On Wed, Oct 18, 2017, at 07:51 AM, Mark Banner wrote: > Looping in firefox-dev as well, as I thin this is an important > discussion. > > On 18/10/2017 09:28, David Teller wrote: > > Hi everyone, > > > >Yesterday, Nightly was broken on Linux and MacOS because of a typo in > > JS code [1].

Re: We need better canaries for JS code

Btw, I believe that there is already support for reporting uncaught errors and that it is blocked by the lack of test harness support. Cheers, David On 18/10/17 19:37, Steve Fink wrote: > My gut feeling is that you'd only want uncaught errors, and > AutoJSAPI::ReportException is a better place

Re: We need better canaries for JS code

On 19/10/2017 03:29, Kris Maglione wrote: On Wed, Oct 18, 2017 at 07:22:09PM -0700, Daniel Veditz wrote: On Wed, Oct 18, 2017 at 4:51 AM, Mark Banner wrote: I did an experiment, and the only way I got an error out was to have "javascript.options.strict" on and Why