18 July, 2015 § 20 Comments
Microsoft is set to release Windows 10 pretty soon and with it comes a new way to set the default browser for your system.
Previous versions of Windows had an API that allowed applications to set themselves as the default application. This worked well and allowed web browsers like Firefox and Chrome to have a single click within their interface to set themselves as the default browser. No extra work was needed by the user after clicking the button within the respective app.
Starting in Windows 10, references to this API now generate the following error dialog on the machine:
Obviously, this message isn’t that helpful. First, users who click on a button to “Make Firefox my Default Browser” now get a dialog telling them what to do instead of doing it for them. Secondly, the message is given in a prompt that blocks interaction with the rest of the computer until the OK button is clicked. Combining this second issue with the lengthy list of steps that the dialog provides makes the situation even worse, as the user will have to memorize this 3-step process before clicking OK.
This experience isn’t something that we want to ship to Firefox users. When I first saw this experience, I sent an email to some people working on Chrome to ask them what their plans were to solve this. They said that they had looked in to this and decided they would instead just open the Settings app to the Default Applications view.
I brought this approach back to some of my coworkers and we decided we would match the behavior that Chrome was using. After all, it didn’t seem like a better solution existed and we certainly didn’t want our users to be seeing the ugly dialog described above.
After I landed the changes in Firefox to open the Settings app, Masayuki Nakano provided an alternative implementation that would open a friendlier looking dialog to set the default application.
This dialog looks a lot better, but it only sets the choice as the default browser if the small “Always use this app” checkbox at the bottom is checked before the OK button is clicked.
Once we had two implementations, we ran an A/B test of them for a week with our Nightly audience.
|Key||Count||Percentage set as Default|
|Alternative Approach/OpenAs (users who did not set the browser as default)||2.35k||53%|
|Alternative Approach/OpenAs (users who did set the browser as default)||2.65k|
|Settings (users who did not set the browser as default)||2.76k||50%|
|Settings (users who did set the browser as default)||2.86k|
The table above shows the data that was collected through the A/B test from June 22 to June 29 with Firefox Nightly 41. This data showed that 53% of alternative-approach users set Firefox as default, whereas 50% of the Settings-app users set Firefox as default.
With only a week of data, we didn’t see a statistical difference between the two approaches and decided we would stick with the Settings app due to it’s wider adoption. We also had issues with the OpenAs approach where we weren’t able to register all protocols and file extensions.
The default browser situation on Windows 10 is pretty bad. There is more work that we can and should do in the Windows 10 upgrade experience to retain users (the default upgrade changes the default browser to Edge).
We also would like to improve our telemetry tracking of the default browser dialog. Ideally we could use some accessibility or automation APIs to scroll into view the Default Browser option within the settings app (it’s scrolled out of view when it is first opened).
6 May, 2015 § Leave a comment
(I’M PROBABLY JINXING MYSELF HERE… KNOCK ON WOOD!)
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.
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
browser.search.showOneOffButtons 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 `
You can download Firefox Beta today to see what it will look like when it hits Release next week.
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:
Bug 1043612 – Persist the size of resizable in-content subdialogs
Bug 1136645 – InContent prefs – Make focusrings match the spec on Windows and Linux
Bug 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.
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:
- Bug 951695 – Consider renaming “Character Encoding” to “Text Encoding”
- Bug 782623 – Name field in Meta tags often empty
- Bug 1124271 – Clicking the reader mode button in an app tab opens reader mode in a new tab
- 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:
- Bug 1054276 – In the “media” view, the “save as” button saves images with the wrong extension
- Bug 732688 – No Help button in the Page Info window
The bugs currently being worked on are:
- Bug 1136526 – Move silhouetted versions of Firefox logo into browser/branding
- Bug 736572 – pageinfo columns should have arrows showing which column is sorted and sort direction
- Bug 418517 – Add “Select All” button to Page Info “Media” tab
- 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.
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.
11 February, 2015 § 3 Comments
Update: Due to a large number of responses, I will be letting people know today, February 14th (instead of the previously mentioned February 13th).
I’m now ready to try something that I’ve been thinking about doing for a little while.
The project will be about six weeks long, starting February 16th and ending March 31st. During this time, I will be available to meet through video chat, IRC (text-based chat), and email.
If you are interested in working with me and have at least two to three years of classroom experience in Computer Science (or equivalent open source experience), please send an email to email@example.com along with:
- Your name
- A short 1-2 sentences about any open source experience you have
- And a rough estimate of how many hours per week you think you could dedicate towards the program.
I’ll let you know if you’ve been accepted by February
13th 14th. Thanks!
31 January, 2015 § 1 Comment
We are now about half-way through the normal development cycle of Firefox 38. In about 3-4 weeks, what is currently “Nightly 38” will become “Firefox Developer Edition 38” (previously known as Firefox Aurora). At this point, beta builds of Firefox 36 will now revert back to the old-school preferences implementation. Firefox Beta will see the in-content preferences get more testing at the beginning of the Beta 37 iteration.
These are some of the bugs that have been fixed since the last update:
Bug 1022582 – Checkboxes and radio buttons in about:preferences lack any indication they’re checked/selected when using High Contrast mode
Bug 1043346 – InContent Prefs – Dialogs should have their dimensions reset after closing
Bug 1008172 – Scrolling up and down on pages with scrollbars in about:preferences will change subgroups (the Advanced subpanes)
Bug 1012223 – in-content preferences loading slowly
I’ve gone through the remaining bugs and attached both a “point” value as well as priorities for the bugs. Point values follow the Fibonacci sequence, and should roughly approximate the difficulty of fixing the bug. Priorities range from P1 to P3.
P1 bugs are considered those that block using the feature, as well as those that are highly visible. We are tracking three P1 bugs:
Bug 1108302 – Font size select list shows ellipsis instead of selected value (points = 1)
Bug 1044597 – in-content preferences: resized dialogs should not push buttons into overflow (points = 3)
Bug 1047586 – Unable to interact with In-content preferences after changing Font size (points = 5)
Big thanks to Richard Marti, Shubham Jindal, and Gijs Kruitbosch for helping to fix the previously-mentioned bugs.