Photon Engineering Newsletter #13

18 August, 2017 § 12 Comments

This week I’m taking over for Dolske as he takes a vacation to view the eclipse. This is issue #13 of the Photon Engineering Newsletter.

This past week the Nightly team has had some fun with the Firefox icon. We’ve seen the following icons grace Nightly builds in the past week:

The icon in the top-left was created in 2011 by Sean Martell. The icon in the top-right was the original Phoenix icon. Phoenix was later renamed Firebird, and then the name was later changed to Firefox. The icon in the bottom left was the first “Firefox” icon, designed by Steven Garrity in 2003. The icon in the bottom-right, well it is such logo with much browser, we couldn’t help ourselves to not share it.

Recent Changes

Menus/structure:

The Report Site Issue button has been moved to the Page Action menu in Nightly and Dev Edition. This button doesn’t ship to users on Beta or Release.

2017-08-18_1554

Probably the biggest visual change this week is that we now have spacers in the toolbar. These help to separate the location bar from the other utility buttons, and also keep the location bar relatively centered within the window. We have also replaced the bookmarks menu button with the Library button (it’s the icon that looks like books on a shelf).

2017-08-18_1557

We also widened various panels to help fit more text in them.

Animation:

The Pin to Overflow animation has also been tweaked to not move as far. This will likely be the final adjustment to this animation (seen on the left). The Pocket button has moved to the location bar and the button expands when a page is saved to Pocket (seen on the right).

Preferences:

Preferences has continued to work towards their own visual redesign for Firefox 57. New icons were landed for the various categories within Preferences, and some borders and margins have been adjusted.

Visual redesign:

The tab label is no longer centered on Mac. This now brings Linux, Mac, and Windows to all have the same visual treatment for tabs.

Changing to Compact density within Customize mode changes the toolbar buttons to now use less horizontal space. The following GIF shows the theme changing from Compact to Normal to Touch densities.

density

Onboarding:

New graphics for the onboarding tour have landed.

Performance:

Two of the main engineers focusing on Performance were on PTO this past week so we don’t have an update from them.

More eslint coverage for Firefox developers

23 January, 2017 § Leave a comment

Since my last post on the eslint work that is happening in mozilla-central, we have increased coverage as well as enabling more rules.

The publication of that post spawned a few conversations, among them Florian Quèze has added a bunch of new Mozilla-specific rules to our eslint configuration and evilpies has started looking at what it would take to run eslint on the JS engine code.

The following rules have been added:

  • newURI originally had three arguments, of which the last two were sparsely used and often had null passed in. Florian converted newURI to make the last two arguments optional, and wrote a script to remove the unneeded null usages. This now has an eslint rule to enforce it.
  • removeObserver had many usages that passed an unused third argument of false. This was most likely done as people were writing code that used addObserver(..., ..., false), and thought that they needed to pass false when calling removeObserver. After that, it most likely got copy-pasted around the codebase. This also now has an eslint rule enforcing people don’t do this again.
  • addEventListener has a {once: true} argument that can be used to automatically remove the event listener after it is called the first time. This rule can be applied to any code that was indiscriminately calling removeEventListener. This work should land very soon, as it just got r+ today. This work is being tracked in bug 1331599.
  • no-undef work continues to make progress as Mark Banner is now focusing on /services subdirectory. We also have a few more globals defined in our configuration and have more testing globals that are imported automatically through a new rule.
  • quotes is now enabled, requiring double-quotes for strings except in cases where double-quotes are used within the string or if the string is a template literal.

While working on no-undef, Mark noticed that the /services directory wasn’t being scanned by eslint even though it wasn’t listed in the .eslintignore file. The directory was missing an .eslintrc.js file. We now have one added in the directory, though there remain 59 warnings which should be fixed (these are listed as warnings temporarily and will be converted to errors once fixed).

Also of note is that we now have automated tests for the custom rules that we have implemented. You can view these tests in the /tools/lint/eslint/eslint-plugin-mozilla/tests directory.

If you’ve got ideas for new rules that we can add to help clean up the codebase, please comment on this post or contact any of us on IRC on the #eslint channel of irc.mozilla.org.

eslint updates for Firefox developers

10 January, 2017 § 1 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 Services.io.newURI 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.

<select> dropdown update 2

14 September, 2016 § Leave a comment

Mike and I met with the “select dropdown” team today and discussed where they’re at and the work that they can focus on for the next week. We are discussing a possible “hack-weekend” October 1st and 2nd at Michigan State.

Freddy got XCode up and running and can debug processes at the single-process/multi-process fork. Jared and Miguel are having issues getting their debugger to work. Freddy will be helping Jared and Miguel with their setup to compare what is different, with the fallback being Jared and Miguel using LLDB as their debugger.

In the past week, the team has also been spending time working on presentations and project plans.

For C++ code, their initial plan was to fake the single-process to run through the multi-process code path by removing the checks for if the code is running in a content process and if a special e10s desktop preference is enabled.

As a quick technical dive: When a select dropdown is clicked, we determine that we’re running in a content process, and we fire an event (“mozshowdropdown”). A content script running in the content process listens for the “mozshowdropdown” event and opens the popup.

The plan to fake the single-process to run through the multi-process won’t work though, because the content script mentioned above won’t be loaded and thus there won’t be an event listener. The content-script is only loaded right now through the remote-browser.xml binding. The content-script would have to be loaded through the non-remote-browser binding (browser.xml) as well as the various message listeners and event listeners.

While working on this, it would be a good idea to move the code from select-child.js to browser-content.js, since we don’t really need a separate file for select items and browser-content.js is loaded in single-process Firefox.

As for styling changes, the students were able to use the Browser Toolbox to change web content through forms.css and see how things like input textboxes could get different default colors. To change the styling of a select dropdown, the students will play around in browser.css to tweak the styling. In the end they’ll want to make sure that the styling exists under the /themes directory, and likely within /themes/shared/.

One of the students asked if we had ideas about specific algorithms or design-patterns that the search-within-the-dropdown implementation should use. We pointed them at the Browser Console’s filtering ability and asked that the students follow the implementation there.

That wraps up our notes from this week’s meeting. We’ll be meeting regularly for the next 10-ish weeks as the students make progress on their work.

Rethinking themes in Firefox

12 September, 2016 § 7 Comments

04b11051730953b648e852e9f9a91623A couple of weeks ago Mike de Boer and I started work on a project to rethink themes in Firefox. At present day, Firefox offers two ways for users to theme their browser: XUL themes (also known as “complete themes”) and lightweight themes (also known as “themes”). We want to create something that gives more power than lightweight themes while also being easier to create and maintain than XUL themes.

Last week we published a survey asking theme authors and users what they like about themes and what they would change. To date, we have received over 250 detailed responses. We will be keeping the survey open and monitoring it for anybody that has not had a chance to reply yet. Here’s what we’ve learned:

Have you made a lightweight theme before?
21.8% yes

What do you like about lightweight themes?
A strong majority (70%) of lightweight theme authors said that they liked how lightweight themes were simple and easy to make. The next group, at 6%, said that they liked how lightweight themes always remain compatible after Firefox updates. 4% of users also liked that they were easy to install with no restart required. A couple people complained that they were too simple and there was too much spam in the themes section of the Add-ons website.

What do you feel was difficult to do or missing from lightweight themes?
A little less than (42%) half of responses would have liked to do more than just a couple of images with lightweight themes. They would like to apply background images to other parts of the browser, change icons, buttons, and the size-of and location of browser components. The next group of responses (10%) wanted more support for scaling, repetition, animation, and position of background images. Improved documentation (8%) and a lack of a development environment such as an in-browser editor followed (6%). The last two groups of responses wanted the ability for themes to change based on external factors (2%) and separate images for the tabs and tab toolbar (2%).

Have you made a XUL theme before?
23% yes

What do you like about XUL themes?
A strong majority of the respondents agreed firmly with 71.2% that XUL themes are awesome in allowing to touch and customize all the things. The second largest group of respondents seek out XUL themes because they offer more nuts and bolts to tinker with than lightweight themes at 11.5%, while the familiarity with the CSS styling language is the main reason to like them for 7.7% of the respondents. Two other notable groups are people who like dark themes, which are apparently only really available as XUL themes, and ones who feel that XUL themes are the easiest thing to make on this planet, each at 3.9%.

What do you feel was difficult to do or missing from XUL themes?
The largest amount of responses (29.8%) said that it is a real pain to keep these themes up-to-date and working, with the current fast release cycle of Firefox and the fast pace of development. 28.1% of the respondents rightfully complained that they need to use exotic, undocumented technologies and unknown CSS selectors in order to create a working XUL theme. Whilst 15.8% claimed there is nothing wrong with XUL themes and we should keep it as-is, another 12.3% is sad about the lack of documentation or any kind of manual to get started. Packaging and delivery of XUL themes is not considered optimal by 10.5% of respondents and that ultimately very few of these themes can be configured after installation (3.5%).

Why do you install themes?
About half (47%) of the survey responses want to personalize Firefox. These people said that they want to make Firefox “their own” and have fun showing it off. They enjoy having full control over the user interface through XUL themes and like the ability to set arbitrary CSS. The next set of responses (16%) asked for a “dark” Firefox, making it easier on the eyes at night. These responses were generally focused on the toolbars and menus of the browser being dark. At 12% of responses was closer integration with the operating system followed closely by 11% of responses saying that they felt the default theme was boring and bland. The last category of responses that received multiple votes was to allow themes to undo recent changes to the user interface, as an attempt to keep things the same that they’ve been for the past months/years.

What capabilities would you like themes to have?
More than half (56%) of the survey responses want full control over the browser UI. They would like to move and hide items, change tab shapes, replace icons, context menus, scrollbars, and more. Following this large group, we had close to 5% of respondents who wanted to simply change basic colors and another group, also close to 5%, that wanted to make it easy for users to make simple tweaks to their browser or an installed theme through a built-in menu or tool. Native OS integration, such as using platform-specific icons and scrollbars, followed closely at 3%. Also at 3% of responses were requests from users who require larger icons and improved readability of the browser’s user interface for improved accessibility. Not far behind, and ironically next in the order of responses, were requests for a smaller browser UI (2%). These users generally want to maximize the amount of screen space that web pages can use. Both “dark themes” and “themes not breaking with future releases” got 2% of responses. In our last group of responses at or above 1% was themes that could change based on external factors (time of day, season, month, web color, or a very slow animation), restartless and easy to trial, ability to apply multiple themes to create a “mash-up”, and to lighten the tab bar.

What parts of Firefox are most important to you to be able to change the appearance of? Why?
Almost 20% of the respondents can not make a choice between the parts of Firefox and thus want to customize the app in its entirety. Following closely with 16% is the group of respondents that think the tabs area is the most important part for themes, while half that number choose toolbars, (toolbar)button icons and the area above the tabs, including the window decoration and window controls. Interestingly, the wish to be able to theme in-content pages is as strong as that of the Awesomebar and respective navigation controls: 6.8%. Changing the colors, palette and fonts used for the UI are the other most notable choices from the community of respondents at 6.4% and 4%, respectively.

Are there theme-related features from other browser or apps that you would like to see incorporated into Firefox?
An overwhelming majority of the respondents insist that we don’t need to change a thing and that other apps don’t offer grand alternatives at 36.5%, or simply can’t think of any. The Vivaldi browser came up in our preliminary research and also takes a prominent position as device of inspiration for theming features at 11.2%. A dark theme like other apps already offer in their package (5.9%), applying tints of color on SVG icons and background masks (2.9%) on UI elements – most notably the titlebar – and take Opera’s about:newtab theming capabilities (2.4%). A notable response from 2.9% of respondents was to introduce a live theme editor in Firefox with sharing capabilities, so that theme creators can take existing themes to tweak to their own liking and (re-)share with others.

The grouping of the results and more details can be found in our meeting notes. Our full archive of meeting notes is also publicly viewable.

Improving <select> dropdowns

9 September, 2016 § 3 Comments

indexLast week marked the beginning of a new 12-week period of mentorship for myself. I’ll be working Mike Conley to share mentorship duties as we mentor a group of five Michigan State University students. The students are all seniors in the Computer Science program.

The MSU Capstone is a program that pairs industry companies with small student groups to give students access to real-world software development and the software development life cycle.

This semester, the five students will be working on improving the visual design of the <select> dropdown. The project has three main components:

  1. The <select> dropdown has two separate implementations: one for single-process Firefox (going away soon), and another for multi-process (e10s) Firefox (the new hotness). The old implementation should be removed, and single-process Firefox should use the implementation that was added as part of the e10s project.
  2. The default look and feel of the <select> dropdown is pretty packed. We want to give more space to the items in the popup to allow for improved readability, as well as making it look more “modern”.
  3. <select> dropdowns have pretty bad usability when the number of items gets very large. They’re also pretty hard to use on touch-screens. The dropdowns should have the ability to filter items and should have more padding when opened via a touch event. The increased padding is intended to make it easier to tap on the desired option as well as to make the options easier to read when they may have a finger hovering over them.
team-photo(left to right) Jared Beach, Fred Luo, Mark Golbeck,
Miguel Wright, Tyler Maklebust

Since the students were assigned to the project last week, they now have local builds up and running as well as Bugzilla accounts. We’ve been active on IRC and will have weekly check-in meetings over Vidyo.

I’ll have more to share in the coming weeks as the students begin ramping up on their work.

Where Am I?

You are currently browsing the Mozilla category at JAWS.