
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Happy to see continued work around tooling, thanks everyone! Here is some of the work I’m currently involved with:<div class=""><br class=""></div><div class="">Coding style</div><div class="">===</div><div class=""><br class=""><div class="">I’ll be extending coding style enforcement to HTML and other markup files. For example, we currently disabled Prettier for JS in HTML and the likes, and I want to turn that back on. Many of our tests are written this way, and there’s no reason why we shouldn’t extend our coding guidelines to cover them. </div><div class=""><br class=""></div><div class="">I’ve also taken a look at various CSS linting and formatting approaches last year, and we can fit those neatly into the current tooling infrastructure we’ve built for C++ and JS. Defining what linting means exactly is slightly trickier for CSS, but I’m confident we can figure out a set of reasonable guidelines to enforce. I’ll keep you posted on the progress as it develops.</div><div class=""><br class=""></div><div class=""><div class="">In terms of what the whole process looks like, as with JS formatting last year, I’ll be coordinating with relman, doing preliminary formatting passes and enabling these checks at commit time/ review time sometime before a merge to limit the impact on the beta uplift process. Leveraging the existing tooling for doing archeology is also a must every time we start formatting bits of our code.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Runtime coverage</div><div class="">===</div><div class=""><br class=""></div><div class="">With the RKV work (unifying key-value data stores across Mozilla), it became clear that we need to start tracking when data corruption happens. We currently have no way of knowing when Firefox users lose their data. Migrating to RKV is going to help with the robustness part, and to prove that it works I’m adding telemetry for tracking these kinds of incidents, for example: 1. data corrupted, we throw it away and 2. data malformed but salvageable.</div><div class=""><br class=""></div><div class="">A broader scope of this kind of investigation is trying to make sense of our profile directory. The RKV work currently limits itself to key-value storage, but the guiding principles of having more robustness can be extended to more than just key-value data. The more we inch towards better telemetry surrounding data robustness, the more we need to have a system in place that tracks what kind of storage we have in our profile directory, what gets added and what gets removed, and equally importantly: what gets corrupted.</div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Victor</div><div><br class=""><blockquote type="cite" class=""><div class="">On 29. Jan 2020, at 09:32, Brian Grinstead <<a href="mailto:bgrinstead@mozilla.com" class="">bgrinstead@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class="">Thanks for bringing this up - I think it’s a great idea.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">We have a few environments to deal with here between parent vs content process combined with chrome vs content privileged. So in general if we can make shared Custom Elements content privileged that will support all environments, and have the benefit of being able to develop/test in a normal web page. We could also consider pulling in third party development tooling like Storybook to make it easier to build and share the components.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">It also would help further XUL element removal as we begin to share the elements with chrome. There will be some details to figure out for scenarios where we currently rely on chrome privilege in the elements for important reasons (like, could we mixin the “content” version of the element when it’s used in chrome as a way to expose these features?). But those are solvable problems and I trust mstriemer would do a good job getting to a consensus and pushing this forward.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Brian</div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Jan 29, 2020, at 8:23 AM, Mike Conley <<a href="mailto:mconley@mozilla.com" class="">mconley@mozilla.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">Oh, one more thing comes to mind here, presuming it's in the scope you had in mind when you started the thread:<br class=""></div><div class=""><br class=""></div><div class="">I've been chatting off and on with mstriemer about looking at ways we can share more UI components between both the browser chrome and the in-content pages. The idea would be to populate toolkit/ with custom elements that are generalized (but customizable) for reuse.</div><div class=""><br class=""></div><div class="">As an example, I think the search inputs in both <a href="about:logins" class="">about:logins</a> and <a href="about:addons" class="">about:addons</a> could be pretty decent candidates for a shared custom element.</div><div class=""><br class=""></div><div class="">-Mike<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 28 Jan 2020 at 10:43, Gijs Kruitbosch <<a href="mailto:gijskruitbosch@gmail.com" class="">gijskruitbosch@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello firefox-dev,<br class="">

<br class="">

It is already almost February, so in the spirit of better late than <br class="">

never: let's talk 2020 planning for improving code quality, <br class="">

maintainability and developer productivity in Firefox!<br class="">

<br class="">

Some of us talked about this at all-hands last night - there is definite <br class="">

room for improvement in our processes and automation aimed at improving <br class="">

the quality of code changes and how productive we all are when working <br class="">

with the code.<br class="">

<br class="">

Some ideas that came up include:<br class="">

<br class="">

- more linting for CSS, HTML, SVG, Fluent and other files (basically, <br class="">

eslint-style linting for non-JS)<br class="">

- type inference in JS<br class="">

- automated infrastructure jobs to get runtime coverage for issues that <br class="">

are harder to check statically (e.g. accessibility, performance)<br class="">

- guidelines/policy/documentation on code, architecture, issues to look <br class="">

out for in reviews, etc.<br class="">

<br class="">

What kind of improvements do you think are most important on the code <br class="">

side of the Firefox/Toolkit codebase, and why? What big things are we <br class="">

missing that you've seen elsewhere?<br class="">

<br class="">

~ Gijs<br class="">

<br class="">

_______________________________________________<br class="">

firefox-dev mailing list<br class="">

<a href="mailto:firefox-dev@mozilla.org" target="_blank" class="">firefox-dev@mozilla.org</a><br class="">

<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank" class="">https://mail.mozilla.org/listinfo/firefox-dev</a><br class="">

</blockquote></div>

<span class="">_______________________________________________</span><br class=""><span class="">firefox-dev mailing list</span><br class=""><span class=""><a href="mailto:firefox-dev@mozilla.org" class="">firefox-dev@mozilla.org</a></span><br class=""><span class=""><a href="https://mail.mozilla.org/listinfo/firefox-dev" class="">https://mail.mozilla.org/listinfo/firefox-dev</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">firefox-dev mailing list<br class=""><a href="mailto:firefox-dev@mozilla.org" class="">firefox-dev@mozilla.org</a><br class="">https://mail.mozilla.org/listinfo/firefox-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>