<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
A 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?
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?
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
Last 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:
- 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.
- 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”.
- <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.
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.
8 September, 2016 § Leave a comment
Just a couple of weeks ago marked the end of my first Outreachy session. During the session I mentored Katie Broida as she worked on some pretty cool features for Firefox.
I learned a lot during the session, and I think she did too. I learned how to advertise and recruit for job openings, gather initial work, and to try to be as attentive as possible for the people that I’m working with.
We started advertising the internship a few weeks before the deadline to apply. Prior to advertising the internship there was little to no outreach to potential applicant pools. In the future, I hope we can reach out to campus groups, hobbyists, and other places that we might find potential candidates. We also need to do this work sooner, as a good number of potential candidates will already have made their internship plans four to six months earlier.
One of the advantages of being an open source company is that Mozilla can help potential applicants get involved in the community far before the application period opens. Applicants can get a chance to see if they will enjoy the work of their internship, and mentors can get a chance to see if the applicants will be successful. This becomes more powerful and insightful than the traditional interview.
As far as Katie’s work, she did an amazing job. Katie fixed numerous bugs throughout the Firefox user interface as well as added a couple new features too. On Windows 10, we now show a larger graphic for the Start Menu tile (it doesn’t work for everyone though, still some ghosts in the shadows here), and for all users we now have a new zoom indicator in the location bar that appears when a site is not at 100% zoom.
Restoring defaults in the Customize Mode now also restores the theme, and she introduced a new API for tab-specific panels to opt-in to closing when the selected tab changes.
Not only did Katie fix a bunch of bugs during the past four months but she also blogged about them, keeping detailed reports about how she got stuck and later how she was able to move around, over, or through the obstacles.
I had a great time working with the Outreachy program and I’ll do it again when Mozilla sponsors another session.
A story of bug fixing
9 April, 2016 § Leave a comment
I spent some time last night looking in to a bug in the Firefox preferences as part of the Outreachy internship I’m mentoring. This bug is about how the context menus in our preferences were squished horizontally compared to normal context menus. I’ve put screenshots of the two below so you can compare.
Looking at bug 1247214, I knew that context menus outside of the preferences looked fine but context menus in the preferences were broken. This meant I had something I could compare side-by-side when looking at the CSS.
I used the inspector and looked at the applied styles for a
xul:menuitem and compared them between the preferences and non-preferences. I was surprised to see that they were nearly identical, and what differed was inconsequential.
After walking up the DOM from the
xul:menuitem and seeing that the two instances were still nearly identical, I had to think of a different route. Somewhat by chance I realized/remembered that there were children nodes of the
xul:menuitem that could possibly be affected. In the Inspector I expanded the
xul:menuitem and looked at the rules for the
xul:label inside of it. Immediately I noticed that the
-moz-margin-end were being set to zero and the rule looked like it wasn’t intended to affect context menus. Unsetting that rule fixed the bug.
So that describes how I found the issue with the bug. Figuring out a fix for it wouldn’t be that difficult now. I also wanted to find what changeset introduced the bug so I could learn more about why it was there.
Using MXR, I pulled up the `hg blame` for the file and went to the offending line. Clicking on the revision number on the left of the line brings up some of the diff from the changeset. At the top of this new page, I clicked on “changeset” to see the full changeset. This unfortunately was a refactoring changeset and wasn’t what actually introduced the offending lines. I then clicked on the parent changeset and based off of that revision found the file again and ran `hg blame` on it. Now the offending line was linked to the changeset that introduced the bug.
After reading through the bug that introduced the changeset I knew that I could safely make this change as the lines were never intended to alter context menus, and I also knew what to look for and test while making the change so I wouldn’t regress the original bugfix.
All of this being said, I probably could have found this quite a bit faster by using a tool called mozregression. mozregression is a tool that will help you run a binary search on all of our nightly builds (continuous integration ones too). As you are likely already aware, binary search is very fast, letting mozregression help narrow down the day that the regression got introduced from a range of 10 years to a single day in about 7 builds.
If I had taken the mozregression route I probably could have saved myself about 45 minutes of debugging and digging around. But both routes work well, and sometimes I learn more from one than the other.
I know this write-up was long, but I hope it was valuable.