
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Thanks for bringing this up - I think it’s a great idea.</div><div dir="ltr"><br></div><div dir="ltr">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"><br></div><div dir="ltr">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"><br></div><div dir="ltr">Brian</div><div dir="ltr"><br><blockquote type="cite">On Jan 29, 2020, at 8:23 AM, Mike Conley <mconley@mozilla.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Oh, one more thing comes to mind here, presuming it's in the scope you had in mind when you started the thread:<br></div><div><br></div><div>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><br></div><div>As an example, I think the search inputs in both about:logins and about:addons could be pretty decent candidates for a shared custom element.</div><div><br></div><div>-Mike<br></div></div><br><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">gijskruitbosch@gmail.com</a>> wrote:<br></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>

<br>

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

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

maintainability and developer productivity in Firefox!<br>

<br>

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

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

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

with the code.<br>

<br>

Some ideas that came up include:<br>

<br>

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

eslint-style linting for non-JS)<br>

- type inference in JS<br>

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

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

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

out for in reviews, etc.<br>

<br>

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

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

missing that you've seen elsewhere?<br>

<br>

~ Gijs<br>

<br>

_______________________________________________<br>

firefox-dev mailing list<br>

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

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

</blockquote></div>

<span>_______________________________________________</span><br><span>firefox-dev mailing list</span><br><span>firefox-dev@mozilla.org</span><br><span>https://mail.mozilla.org/listinfo/firefox-dev</span><br></div></blockquote></body></html>