eslint updates for Firefox developers

10 January, 2017 § Leave a comment

In the past week there has been quite a lot of progress made on the eslint front.

Last week I enabled the following rules for the default mozilla-central eslint configuration (/toolkit/.eslintrc.js):

Mark Banner has continued to work on fixing the remaining no-undef errors. This work is on-going and is being tracked by a meta bug.

Florian Quèze just landed a patch yesterday to simplify calls to so the two trailing arguments are optional. Previously 99% of the calls to the function passed in null for the trailing arguments. Florian is planning on cleaning up some addEventListener code as well and I am pushing for him to implement special eslint rules along with them to help enforce these changes going forward.

I enabled most of the rules for eslint and gathered counts of the number of errors related to each rule. The following list shows each disabled rule along with the number of associated errors as of mozilla-central revision f13abb8ba9f3:

  • array-callback-return = 3
  • no-new-func = 13
  • no-useless-concat = 14
  • no-void = 14
  • no-multi-str = 15
  • no-new-wrappers = 18
  • no-array-constructor = 20
  • no-eval = 20
  • no-await-in-loop = 21
  • no-sequences = 22
  • no-inner-declarations = 23
  • no-unmodified-loop-condition = 24
  • wrap-iife = 25
  • no-constant-condition = 28
  • no-template-curly-in-string = 39
  • no-loop-func = 44
  • no-fallthrough = 51
  • no-new = 56
  • no-throw-literal = 134
  • no-prototype-builtins = 158
  • no-caller = 165
  • no-unused-expressions = 171
  • no-useless-escape = 194
  • complexity = 208
  • no-case-declarations = 238
  • guard-for-in = 284
  • radix = 342
  • no-shadow = 356
  • no-eq-null = 442
  • dot-notation = 459
  • default-case = 485
  • block-scoped-var = 749
  • no-empty-function = 1144
  • dot-location = 2327
  • no-extra-parens = 2464
  • no-invalid-this = 2947

If you would like to work on fixing any of these, please file a bug in the Toolkit :: General component of Bugzilla and request review from myself, Mossop, or Standard8.

If you’d like eslint to run on a directory that you work in, remove the reference to it from the .eslintignore file located at the mozilla-central root and add a .eslintrc.js file. This will now allow eslint to scan that directory.

Also, another project that someone can pick up is to help us move towards a single rule definition. We would like to move to a single set of rules which will help for consistent coding styling. You can look at this listing of .eslintrc.js files to see the differences between them. Some define globals that are unique to the directory or have different include paths to the root configuration, but some also define extra rules. We would like to get those rules added to the root configuration, though we haven’t determined how to settle rule conflicts yet.

<select> dropdown update 3

14 December, 2016 § 1 Comment

First, let me say that the students working on this project have done a great job. Secondly, let me say that I’ve not done a great job blogging about their work. I will try to make up for it in this post.

Since the previous post a lot has happened: we had our hack-weekend at MSU, the students implemented the features we asked them to work on, a bonus feature got implemented, the students made a video about their project, and then they presented their project as part of their end-of-the-semester Design Day exhibition.

I’ll go through each item of the above list:

Our “hack-weekend” at MSU

On about the fifth weekend of the project, Mike and I visited the MSU campus to work with the students and familiarize them with the project and the Mozilla codebase. We covered all aspects of the tools: Bugzilla, Mercurial, Reviewboard, and the Browser Toolbox. We gave short lessons on interprocess communication, low-level CSS styling implementation, and distributed version control systems.

What worked

  • The location and facilities were great. We had solid connections to the internet, a comfortable room, and no hassles.
  • The team was very astute and asked many questions as we were going along.
  • Bugzilla and Reviewboard seemed to get understood well.
  • There was tons of paired programming and hacking on the project, and great career discussions as well.
  • The students wrote some amazing automated tests for searching in the dropdown. It is great to give students a real-world project that includes so many parts of good software development (automated tests, code reviews, version control, paired programming, code linting, and fixing regression bugs).

What didn’t work

  • I think we should have done the hack weekend a little sooner in the semester. The sooner the better, as we can try to get ahead of any tooling issues, ambiguities in the spec, and technologies that should be covered. For example, at the beginning of the semester I asked that each student complete a set of online tutorials. After going through the lessons I got the feeling that there was still some room to grow and understand more about the programming languages we were using.
  • Mercurial seemed very hard to get a grasp of. Some of this may have been due to the paired programming where the students were sharing patches, and the rest is probably due to Mike and I not having a solid plan at the beginning of the semester as to how the students can share and update each others patches. We should probably set up a non-publishing user repo that all students will have access to and push to as they are working on the project.
  • The students used Mercurial’s bookmark-based development model, and I still use the Mercurial Queues method. This meant that I wasn’t much help when the students got stuck. I’m switching my development model to bookmark-based development before the next semester starts.
  • Two of the groups of students were paired up. This seemed to work OK in the beginning, but soon it seemed that the students weren’t doing a good job of switching off. I think we will try to do less pairing at the beginning, and maybe introduce pairing towards the end once the students have gotten a grasp of the tools, codebase, and project requirements.

The work that got completed

Mark landed the styling changes for the dropdown. The dropdowns now have more padding around each item, show a grey background for theheaders, and have correct hover styling. All of this work was for Windows-only, as Linux and OSX looked fine already.

Mark also landed a patch to increase the padding of items when the dropdown is opened on a touch-enabled device. I landed a small follow-up to only show the increased padding when a touch-event was used to open the dropdown.

Jared landed an OSX-only patch to open the dropdown vertically centered on the selected item. This brings us in parity with Safari on OSX. We may possibly do the same for Windows now that Edge is showing the behavior there, though it is not planned for anytime soon. This feature was a bonus, as we didn’t expect the students to have the time to get to it when the project was started.

The work that is near completion

Tyler and Jared worked on implementing search within the dropdown. The search box only shows up if there are over 40 items in the list, and it will provide live filtering of the menuitems. There are some cool automated tests that Tyler wrote that verify the functionality works. These tests will be easy to expand upon in the future if any regressions are found or the feature is to get expanded. This is pretty close to landing and will hopefully land this week or next, depending on how quick the students are at responding to the review feedback.

Michael and Fred worked on getting single-process Firefox to use the multi-process Firefox implementation of the <select> dropdowns. This work was pretty low-level and required the students to set up a debugger on a separate machine and use remoting to control the browser (to avoid issues with focus changing). This is getting pretty close to landing, but will need a separate bug fixed first before the students can push further on it. I hope we can get it to land in the next couple weeks.

Project video

As part of the course requirements, the students made a video to showcase their work. Watch below, it’s pretty good (and funny too!)

Sorry for not blogging about their project more often. The students did a great job on the project and we hope to see them stay active in the Mozilla community going forward.

Polishing Firefox for Windows 10

22 July, 2015 § 12 Comments

Over the years, the Firefox front-end team has made numerous polishes and updates to the Firefox theme.

Firefox 4 was a huge update to the user interface of Firefox compared to Firefox 3.6. A couple years down the line we released Australis in Firefox 29. Next month we’ll be releasing Firefox 40 and with it will come with what I believe to be the most polished UI we’ve shipped to date.

The Australis release was great in so many ways. It may have taken a bit longer than many had expected to get released, but much of that was due to the complexities of the Firefox theme code. During the Australis release we removed some lesser used features which consistently were a pain in the rear when making theme changes (small icons and icons+text mode, I’m looking at both of you 👀).

Now with Firefox 40, we’re able to show the benefits of our refined theme code and our ability to ship updated and modern themes much faster than ever before.

With Firefox 40 on Windows 10, which you can download today using the Firefox Beta channel, we’ve matched the tabstrip and toolbar to the native Windows 10 theme. This includes refinements to our standard icon set, as well as much improved HiDPI (>1dppx) support. All of our first-tier icons now have 2× variants that are shipped with the browser, and the remaining icons buried in the depths of the browser should be fixed soon as well.

My favorite feature of Firefox on Windows 10 is the increased URL and search bar height (pictured above). This is actually something that we’ve wanted to do for a couple years. Firefox has continually had a pretty small font-size for the URL bar, one which makes it hard for users with poor vision to read. The text in our URL and search bars is now on-par with competing browsers. It may not seem like a big deal to most, but it is the small cuts like these that can either add up to cause death by a thousand wounds or be part of the stitches in a bullet-proof product.

Cheers 😊

Final In-content Preferences status update

6 May, 2015 § Leave a comment



We are now a week away from the release of Firefox 38, and with it will finally come the release of in-content preferences. You can download Firefox Beta today to see what it will look like when it hits Release next week.

I want to give a huge thanks to all of the people who worked on the project. You all helped it get to the point where hundreds of millions of people will get to see a refreshed and modern preference experience.

Major thanks goes out to Stephen Horlander, Michael Maslaney, Madhava Enros, Gijs Kruitbosch, Blair McBride, Richard Marti, Tim Nguyen, Justin Dolske, Zhenshuo Fang, Dão Gottwald, Tim Taubert, Matthew Noorenberghe and a huge host of other people that have helped.

Known issues:
1) Dialogs opened in the Advanced pane don’t use the same tab-modal dialog implementation that can be found within the rest of the preferences. We hope to get this fixed in a future release very soon.
2) The design for focus rings within the preferences still has a refresh coming, but it won’t make Firefox 38. As with #1, we hope to get this in to a future release very soon.
3) If you have gone to about:config and set to `false`, the Search pane of the preferences is broken. The fix for this didn’t make the 38.0 cut-off, but it will be fixed within the next few weeks following release. Going forward this preference will be removed, so now may be a good time to revert that preference back to `true`.

Other lower-impact known issues can be found on Bugzilla.

You can download Firefox Beta today to see what it will look like when it hits Release next week.

Status update – In-content Preferences, part 5

4 March, 2015 § 4 Comments


Firefox 38 has now merged to Aurora (Firefox Developer Edition) and we are a couple weeks into development of Firefox 39 on mozilla-central. At this point, bugs that are fixed on mozilla-central will need to be uplifted to mozilla-aurora to continue to ride the 38 train.

These are some of the 21 bugs that were fixed since the last update (1/31/2015):

  • Bug 1008171 No focus for elements except textboxes (and buttons, on Windows and Linux) inside in-content preferences
  • Bug 1025719 – openPreferences(panelName) doesn’t open the requested pane if about:preferences is in a yet-to-be-loaded tab
  • Bug 1034296 – Action dropdown in Application pane does not open when session restored
  • Bug 1037225 – Consider keeping browser.preferences.instantApply = false on Windows
  • Bug 1044597 – in-content preferences: resized dialogs should not push buttons into overflow
  • Bug 1047586 – Unable to interact with in-content preferences after changing minimum font size to a very large value
  • Bug 1108302 – Menulists in the in-content preferences have too much padding at the start of their contents
  • Bug 1111353 – No longer displayed check mark in in-content preferences if Text : white, Background : Black and Select “Never” in “Content” > “Colors…” > “Allow pages to choose their own colors, instead of my selections above”

Since the last update all of the P1-tracked bugs have been fixed. We are tracking the following P2 bugs:
top_2Bug 1043612 – Persist the size of resizable in-content subdialogs
top_2Bug 1136645 – InContent prefs – Make focusrings match the spec on Windows and Linux
top_2Bug 1044600 – in-content preferences: empty dialogs after pressing backspace or the Back button

Bug 1044600 in the above list should be very close to getting fixed. It has landed and been backed out a couple times due to intermittent failures and leaks, but is making steady progress towards being fixed.

Gijs and I will be meeting up in less than two weeks in San Francisco to have a “hack week” focusing on the in-content preferences. We’ve gone through the list of bugs in the in-content preferences and put together a subset of 10 bugs that we’ll tackle during the week if they’re not fixed beforehand.

Big thanks go out to Ian Moody [:Kwan], Gijs, Yash Mehrotra, Richard Marti [:Paenglab], and Tim Nguyen [:ntim] for their help in fixing the 21 bugs.

An update on my mentoring program

2 March, 2015 § Leave a comment

Today is the start of the third week of the mentoring program.

Since the start of the program, four bugs have been marked fixed:

  1. Bug 951695 – Consider renaming “Character Encoding” to “Text Encoding”
  2. Bug 782623 – Name field in Meta tags often empty
  3. Bug 1124271 – Clicking the reader mode button in an app tab opens reader mode in a new tab
  4. Bug 1113761 – Devtools rounds sizes up way too aggressively (and not reflecting actual layout). e.g. rounding 100.01px up to 101px

Also, the following bugs are in progress and look like they should be ready for review soon:

  1. Bug 1054276 – In the “media” view, the “save as” button saves images with the wrong extension
  2. Bug 732688 – No Help button in the Page Info window

The bugs currently being worked on are:

  1. Bug 1136526 – Move silhouetted versions of Firefox logo into browser/branding
  2. Bug 736572 – pageinfo columns should have arrows showing which column is sorted and sort direction
  3. Bug 418517 – Add “Select All” button to Page Info “Media” tab
  4. Bug 967319 – Show a nodesList result with natural order

I was hoping to have 8-9 bugs fixed by this time, but I’m happy with four bugs fixed and two bugs being pretty close. Bug 967319 in the “being worked on” section is also close, but still needs work with tests before it can be ready for review.

Starting of my new mentoring program

16 February, 2015 § Leave a comment

Today starts the first day of the mentoring program that I announced in my previous blog post.

In good news, I was overwhelmed by the number of responses I received to the blog post. Within three days, 57 people sent me an email requesting to be a part of the program. This tells me there is a strong need for more guided programs like this. On the downside, it was very hard to select only four people from the group.

In the end, I ended up selecting five people to partake in this. They are from all over the world: India (2); Germany; and USA (2).

I have assigned the first bugs and work should proceed this week on getting a build working and finding their way through the Firefox developer ecosystem.

Where Am I?

You are currently browsing entries tagged with mozilla at JAWS.