Mozilla Firefox

I was invited by Sandra Persing to participate to the Mozilla Developer Roadshow 2019 in Asia. The event is going through 5 cities: Tokyo, Seoul, Taipei, Singapore, Bangkok. I committed to participate to Tokyo and Seoul. The other speakers are still ... [More] on the road. As I'm writing this, they are speaking in Taipei, when I'm back home. Let's go through the talk and then some random notes about the audience, people and cities. The Webcompat Talk The talk was half about webcompat and half about the tools helping developers using Firefox to avoid Web compatibility issues. The part about the Firefox devtools was introduced by Daisuke. My notes here are a bit longer than what I actually said. I have the leisure of more space. Let's talk about webcompat The market dominance by one browser is not new. It has happened a couple of times already. In an article by Wired on September 2008 (Time flies!), they have this nice graph about the browser market share space. The first dominant browser was Netscape in 1996, the child of Mosaic. It already had influence on the other player. I remember how the introduction of images and tables. For example, I remember a version of Netscape where we had to close the table element absolutely. If not, the full table was not being displayed. This had consequences on the web developer job-At that time, we were webmasters. This seems to be a good consequence in this case by imposing a cleaner, leaner code. Then Internet Explorer entered the market and took it all. The browser being distributed with Windows, it became de factor the default engine in all work environments. Internet Explorer reached his dominance peak around 2003, then started to decline through the effort of Firefox. Firefox never reached a peak (and that's good!). Probably the maximum market share in the world was around 20%-30% in 2009. Since there has been a steady decline of Firefox market share. The issue is not the loss of market share, the issue is the dominance by one player whichever the player is. I would not be comfortable to have Firefox as a dominant browser too. A balance in between all browsers is healthy. note: World market shares are interesting, but they do not represent the full picture. There can be extreme diversity in between markets. That was specifically the case 10 years ago. A browser would have 80% of the market share in a specific country and 0% in another one. The issue is increased through mobile operators. It happened on Japan market, which went from 0 to very high dominance of Safari on iOS, to a shared dominance in between Chrome (Android) and Safari (iOS). The promises of a website When a website is sold to a client. We sell the package, the look and feel, the design. In the cases of web applications, performances, conversion rates, user engagement pledge will be added into the basket. We very rarely talk about the engine. And still, people are more and more conscious about the quality and origin of food they buy, the sustainability of materials used to build a house, the maintenance cost of their car. There is a lot of omissions in what is being promised to the client. This is accentuated by the complete absence of thinking about the resilience of the information contained on the website. Things change radically when we introduce the notion of archivability, time resilience, robustness over devices diversity and obsolescence. These are interesting questions that should be part of the process of thinking a website. years ago websites were made of files; now they are made of dependencies. — Simon Pitt A simple question such as "What the content of this page becomes when the site is not updated anymore and the server is not maintained anymore?" A lot of valuable information disappears every day on the Web, just because we didn't ask the right questions. But I'm drifting a bit from webcompat. Let's come back on track. The reality of a website And here the photo of an actual website. This is dirty, messy, full of dependencies, and forgotten bits. Sometimes different version of the same library is used in the code with conflicting ways of doing things. CSS is botched, JS is in a dire state of complexity, html and accessibility are a deeply nested soup of codes where the meaning has been totally forgotten. With the rise of frameworks such as ReactJS and their components, we fare a lot of worse in terms of semantics than what we did a couple of years ago with table layouts. These big piles of codes have consequences. Maintainability suffers. Web compatibility issues increase. By Web compatibility I mean the ability of a website to work correctly on any devices, any context. Not as it should look the same everywhere, but as in any users should be able to perform the tasks they were expecting doing on it. Examples? Misconfigured user agent sniffing creating a ping-pong game (http/JS redirection) in between a mobile and a desktop site. User agent detection in JavaScript code to deliver a specific feature, which fails when the user agent change, or the browser is being fixed. Detection of a feature to change the behavior of the browser. window.event was not standard, and not implemented in Firefox for a long time. Webcompat issues pushed Mozilla to implement it for solving issues. In return, it created new webcompat issues, because some sites where using this to mean Firefox and not IE and then choose in between keyCode and charCode, which had yet another series of unintended consequences. WebKit prefixes for CSS and JS… Circa 2015, 20% of the Japanese and Chinese mobile websites were breaking in a way or the other on Firefox on Android. It make impossible to have a reasonable impact on the Japanese market or to create an alliance with an operator to distribute Firefox more widely. So some of the WebKit prefixes became part of the Web platform, because you can't exist when developing a new browser if you do not have these aliases. Forget about asking web developers to do the right thing. Some sites are not maintained anymore, but users are still using them. The list goes on. The ultimate victim? The user who decided to use a specific browser for personal reasons is the victim. They are caught in between a website not doing the right thing, and a tool (the browser) not working properly. If you are not the user of the dominant browser of the market, you are up for a bumpy ride on the Web. Your browser usage becomes more a conviction of doing the right thing, more than making your life easier. This should not. A form to save the Web We, the Web compatibility team, created a form to help users report issues about website working in one browser but not the others. The report can be made for any browsers, not only Mozilla Firefox (for which I'm working). The majority of our issues are coming from Firefox for two reasons. Firefox not having a market dominance, web developers do not test in Firefox. It's even more acute on mobile. The bug reporting is integrated into the Firefox UI (Developer, Nightly releases). When we triage the issues, an amazing team of 3 persons (Ciprian, Oana and Sergiu), we ping the right persons working for other browsers companies for analyzing the issues. I would love more participation from the other browsers, but the participation is too irregular to make it effective for other browsers. On Mozilla side, we have a good crew. Diagnosis: a web plumbers team Every day, someone on the Mozilla webcompat team (Dennis, Ksenia, Thomas and myself) will handle the diagnosis of incoming issues. We call this diagnosis. You remember the messy website picture? Well, we put our sleeves up and dig right into the greasy bolts and screws. Minified code, broken code, unmaintained libraries, ill-defined CSS, we go through it and try to make sense of it without sometimes access to the original sources. Our goal is to determine if it's really one of these: not a webcompat issue. There's a difference but created by different widget rendering, or browser features specific to one vendor (font inflation for example) a bug in Gecko (core engine of Firefox) that needs to be fixed a mistake of the website Once the website has been diagnosed, we have options… Charybdis and Scylla: Difficult or… dirty The options once we know what the issue is are not perfect. Difficult: We can try to do outreach. It means trying to find out the owner of the website or the developer who created it. It's a very difficult task to discover who is in charge and is very dependent on the country and type of business the site is doing. Contacting a bank site and getting it fixed is nearly impossible. Finding a Japanese developer of a big corporation website is very hard (a lot of secrecy is going around). It's a costly process, with not always great results. If you are part of the owners of broken websites, please contact us. Probably we should create a search engine for broken websites. So people can find their own sites. Dirty: The other option is to fix on the browser side. The ideal scenario is when there is really a bug in Firefox and Mozilla needs to fix it. But sometimes, the webcompat team is pushing Gecko engineers to introduce dirty fix into the code, so Firefox can be compatible with what a big website is doing. These can be a site intervention that will modify the code on the fly or it can be a more general issue which requires to fix both the browser and the technical specification. The specification… ??? Yes. Back to the browser market share and its influences on the world. If a dominant browser implements wrongly the specification, it doesn't matter what is right. The Web developers will plunge into using the feature as it behaves in the dominant browser. This solidifies the technical behavior of a feature and creates the burden of implementing a different behavior on smaller browsers, and then changing the specification to match what everyone was forced to implement. The Web is amazing! All of that said, the Web is an amazing place. It's a space which gave us the possibility to express ourselves, to discover each other, to work together, to create beautiful things on a daily basis. Just continue doing that, but be mindful that the web is for everyone. Notes from a dilettantish speaker I wanted to mention a couple of things, but I think I will do that in a separate blog post with other things that have happened this week. Otsukare! [Less]

Were they on a break or not?! For nearly a decade, Ross and Rachel’s on-screen relationship was a point of contention for millions of viewers around the world. It’s no … Read more The post Here’s why pop culture and passwords don’t mix appeared first on The Firefox Frontier.

Were they on a break or not?! For nearly a decade, Ross and Rachel’s on-screen relationship was a point of contention for millions of viewers around the world. It’s no … Read more The post Here’s why pop culture and passwords don’t mix appeared first on The Firefox Frontier.

At Github Universe, Github announced the GitHub Security Lab, an initiative to help secure open source software alongside the community and an initial set of partners including Mozilla. As part of this announcement, Github is providing free access to ... [More] CodeQL, a security research tool which makes it easier to identify flaws in open source software. Mozilla has used these tools privately for the past two years, and have been very impressed and hopeful about how these tools will improve software security. Mozilla recognizes the need to scale security to work automatically, and tighten the feedback loop in the development <-> security auditing/engineering process. One of the ways we’re supporting this initiative at Mozilla is through renewed investment in automation and static analysis. We think the broader Mozilla community can participate, and we want to encourage it. Today, we’re announcing a new area of our bug bounty program to encourage the community to use the CodeQL tools.  We are exploring the use of CodeQL tools and will award a bounty – above and beyond our existing bounties – for static analysis work that identifies present or historical flaws in Firefox. The highlights of the bounty are: We will accept static analysis queries written in CodeQL or as clang-based checkers (clang analyzer, clang plugin using the AST API or clang-tidy). Each previously unknown security vulnerability your query matches will be eligible for a bug bounty per the normal policy. The query itself will also be eligible for a bounty, the amount dependent upon the quality of the submission. Queries that match historical issues but do not find new vulnerabilities are eligible. This means you can look through our historical advisories to find examples of issues you can write queries for. Mozilla and Github’s Bug Bounties are compatible not exclusive so if you meet the requirements of both, you are eligible to receive bounties from both. (More details below.) The full details of this program are available at our bug bounty program’s homepage. When fixing any security bug, retrospective is an important part of the remediation process which should provide answers to the following questions: Was this the only instance of this issue? Is this flaw representative of a wider systemic weakness that needs to be addressed? And most importantly: can we prevent an issue like this from ever occurring again? Variant analysis, driven manually, is usually the way to answer the first two questions. And static analysis, integrated in the development process, is one of the best ways to answer the third. Besides our existing clang analyzer checks, we’ve made use of CodeQL over the past two years to do variant analysis. This tool allows identifying bugs both in the context of targeted, zero-false-positive queries, and more expansive results where the manual analysis starts from a more complete and less noise-filled point than simple string matching. To see examples of where we’ve successfully used CodeQL, we have a meta tracking bug that illustrates the types of bugs we’ve identified. We hope that security researchers will try out CodeQL too, and share both their findings and their experience with us. And of course regardless of how you find a vulnerability, you’re always welcome to submit bugs using the regular bug bounty program. So if you have custom static analysis tools, fuzzers, or just the mainstay of grep and coffee – you’re always invited. Getting Started with CodeQL Github is publishing a guide covering how to use CodeQL at https://securitylab.github.com/tools/codeql Getting Started with Clang Analyzer We currently have a number of custom-written checks in our source tree. So the easiest way to write and run your query is to build Firefox, add ‘ac_add_options –enable-clang-plugin’ to your mozconfig, add your check, and then ‘./mach build’ again. To learn how to add your check, you can review this recent bug that added a couple of new checks – it shows how to add a new plugin to Checks.inc, ChecksIncludes.inc, and additionally how to add tests. This particular plugin also adds a couple of attributes that can be used in the codebase, which your plugin may or may not need. Note that depending on how you view the diffs, it may appear that the author modified existing files, but actually they copied an existing file, then modified the copy. Future of CodeQL and clang within our Bug Bounty program We retain the ability to be flexible. We’re planning to evaluate the effectiveness of the program when we reach $75,000 in rewards or after a year. After all, this is something new for us and for the bug bounty community. We—and Github—welcome your communication and feedback on the plan, especially candid feedback. If you’ve developed a query that you consider more valuable than what you think we’d reward – we would love to hear that. (If you’re keeping the query, hopefully you’re submitting the bugs to us so we can see that we are not meeting researcher expectations on reward.) And if you spent hours trying to write a query but couldn’t get over the learning curve – tell us and show us what problems you encountered! We’re excited to see what the community can do with CodeQL and clang; and how we can work together to improve on our ability to deliver a browser that answers to no one but you. The post Adding CodeQL and clang to our Bug Bounty Program appeared first on Mozilla Security Blog. [Less]

At the end of October, the Firefox add-ons team hosted a day-long meetup with a group of privacy extension developers as part of the Mozilla Festival in London, UK. With 2019 drawing to a close, this meetup provided an excellent opportunity to hear ... [More] feedback from developers involved in the Recommended Extensions program and to get input about some of our plans for 2020. Recommended Extensions Earlier this summer we launched the Recommended Extensions program to provide Firefox users with a list of curated extensions that meet the highest standards of security, utility, and user experience. Participating developers agree to actively maintain their extensions and to have each new version undergo a code review. We invited a handful of Recommended developers to attend the meetup and gather their feedback about the program so far. We also discussed more general issues around publishing content on addons.mozilla.org (AMO), such as ways of addressing user concerns over permission prompts. Scott DeVaney, Senior Editorial & Campaign Manager for AMO, led a session on ways developers can improve a few key experiential components of their extensions. These tips may be helpful to the developer community at large: AMO listing page. Use clear, descriptive language to convey exactly what your extension does and how it benefits users. Try to avoid overly technical jargon that average users might not understand. Also, screenshots are critical. Be sure to always include updated, relevant screenshots that really capture your extension’s experience. Extension startup/post-install experience. First impressions are really important. Developers are encouraged to take great care in how they introduce new users to their extension experience. Is it clear how users are supposed to engage with the content? Or are they left to figure out a bunch of things on their own with little or no guidance? Conversely, is the guidance too cumbersome (i.e. way too much text for a user to comfortably process?) User interface. If your extension involves customization options or otherwise requires active user engagement, be sure your settings management is intuitive and all UI controls are obvious. Monetization. It is of course entirely fine for developers to solicit donations for their work or possibly even charge for a paid service. However, monetary solicitation should be tastefully appropriate. For instance, some extensions solicit donations just after installation, which makes little sense given the extension hasn’t proven any value to the user yet. We encourage developers to think through their user experience to find the most compelling moments to ask for donations or attempt to convert users to a paid tier. WebExtensions API and Manifest v3 One of our goals for this meetup was to learn more about how Firefox extension developers will be affected by Chrome’s proposed changes to their extensions API (commonly referred to as Manifest v3).  As mentioned in our FAQ about Manifest v3, Mozilla plans to adopt some of these changes to maintain compatibility for developers and users, but will diverge from Chrome where it makes sense. Much of the discussion centered around the impact of changes to the `blocking webRequest` API and replacing background scripts with service workers. Attendees outlined scenarios where changes in those areas will cause breakage to their extensions, and the group spent some time exploring possible alternative approaches for Firefox to take. Overall, attendees agreed that Chrome’s proposed changes to host permission requests could give users more say over when extensions can run. We also discussed ideas on how the WebExtensions API could be improved in light of the goals Manifest v3 is pursuing. More information about changes to the WebExtensions API for Manifest v3 compatibility will be available in early 2020. Many thanks to everyone who has contributed to this conversation over the last few months on our forums, mailing list, and blogs! Firefox for Android We recently announced that Firefox Preview, Mozilla’s next generation browser for Android built on GeckoView, will support extensions through the WebExtensions API. Members of the Android engineering team will build select APIs needed to initially support a small set of Recommended Extensions. The group discussed a wishlist of features for extensions on Android, including support for page actions and browser actions, history search, and the ability to manipulate context menus. These suggestions will be considered as work on Firefox Preview moves forward. Thank you Many thanks to the developers who joined us for the meetup. It was truly a pleasure to meet you in person and to hear first hand about your experiences. The add-ons team would also like to thank Mandy Chan for making us feel at home in Mozilla’s London office and all of her wonderful support during the meetup. The post 2019 Add-ons Community Meetup in London appeared first on Mozilla Add-ons Blog. [Less]

Happy Things Thursday! Today we are releasing WebThings Gateway 0.10. If you have a gateway using our Raspberry Pi builds then it should already have automatically updated itself. This new release comes with support for thermostats and smart locks ... [More] , as well as an updated add-ons system including extension add-ons, which enable developers to extend the gateway user interface. We’ve also added localisation settings so that you can choose your country, language, time zone and unit preferences. From today you’ll be able to use the gateway in American English or Italian, but we’re already receiving contributions of translations in different languages! Thermostats Version 0.10 comes with support for smart thermostats like the Zigbee Zen Thermostat, the Centralite HA 3156105 and the Z-Wave Honeywell TH8320ZW1000. You can view the current temperature of your home remotely, set a heating or cooling target temperature and set the current heating mode. You can also create rules which react to temperature or control your heating/cooling via the rules engine. In this way, you could set the heating to come on at a particular time of day or change the colour of lights based on how warm it is, for example. Smart Locks Ever wonder if you’ve forgotten to lock your front door? Now you can check when you get to work, and even lock or unlock the doors remotely. With the help of the rules engine, you can also set rules to lock doors at a particular time of day or notify you when they are unlocked. So far we have support for Zigbee and Z-Wave smart locks like the Yale YRD226 Deadbolt and Yale YRD110 Deadbolt. Extension Add-ons Version 0.10 also comes with a revamped add-ons system which includes a new type of add-on called extensions. Like a browser extension, an extension add-on can be used to augment the gateway’s user interface. For example, an extension can add its own entry in the gateway’s main menu and display its own dedicated screen with new functionality. Together with a new mechanism for add-on developers to extend the gateway’s REST API, this opens up a whole new world of possibilities for add-on developers to customise the gateway. Note that the updated add-ons system comes with a new manifest format inspired by Web Extensions. Michael Stegeman’s blog post explains in more depth how to use the new add-ons system. We’ll walk you through building your own extension add-on. Localisation Settings Many add-ons use location-specific data like weather, sunrise/sunset and tide times, but it’s no fun to have to configure your location for each add-on. It’s now possible to choose your country, time zone and language via the gateway’s web interface. With time zone support, time-based rules should now correctly adjust for daylight savings time in your region. Since the gateway is configured to use Greenwich Mean Time by default, your rules may show times you didn’t expect at first. To fix this, you’ll need to set your time zone appropriately and adjust your rule times. You can also set your preference of unit used to display temperature, to either degrees Celsius or Fahrenheit. And finally, many of you have asked for the user interface to support multiple languages. We are shipping with an Italian translation in this release thanks to our resident Italian speaker Kathy. We already have French, Dutch and Polish translations in the pipeline thanks to our wonderful community. Stand by for more information on how to contribute to translations in your language! API Changes & Standardisation For developers, in addition to the new add-ons system, it’s now possible to communicate with all the gateway’s web things via a single WebSocket connection. Previously it was necessary to open a WebSocket per device, so this is a significant enhancement. We’ve recently started the Web Thing Protocol Community Group at the W3C with the intention of standardising this WebSocket sub-protocol in order to further improve interoperability on the Web of Things. We welcome developers to join this group to contribute to the standardisation process. Coming Soon Coming up next, expect Mycroft voice controls, translations into more languages and new ways to install and use WebThings Gateway. As always, you can head over to the forums for support. And we welcome your contributions on GitHub. The post Thermostats, Locks and Extension Add-ons – WebThings Gateway 0.10 appeared first on Mozilla Hacks - the Web developer blog. [Less]

Happy Things Thursday! Today we are releasing WebThings Gateway 0.10. If you have a gateway using our Raspberry Pi builds then it should already have automatically updated itself. This new release comes with support for thermostats and smart locks ... [More] , as well as an updated add-ons system including extension add-ons, which enable developers to extend the gateway user interface. We’ve also added localisation settings so that you can choose your country, language, time zone and unit preferences. From today you’ll be able to use the gateway in American English or Italian, but we’re already receiving contributions of translations in different languages! Thermostats Version 0.10 comes with support for smart thermostats like the Zigbee Zen Thermostat, the Centralite HA 3156105 and the Z-Wave Honeywell TH8320ZW1000. You can view the current temperature of your home remotely, set a heating or cooling target temperature and set the current heating mode. You can also create rules which react to temperature or control your heating/cooling via the rules engine. In this way, you could set the heating to come on at a particular time of day or change the colour of lights based on how warm it is, for example. Smart Locks Ever wonder if you’ve forgotten to lock your front door? Now you can check when you get to work, and even lock or unlock the doors remotely. With the help of the rules engine, you can also set rules to lock doors at a particular time of day or notify you when they are unlocked. So far we have support for Zigbee and Z-Wave smart locks like the Yale YRD226 Deadbolt and Yale YRD110 Deadbolt. Extension Add-ons Version 0.10 also comes with a revamped add-ons system which includes a new type of add-on called extensions. Like a browser extension, an extension add-on can be used to augment the gateway’s user interface. For example, an extension can add its own entry in the gateway’s main menu and display its own dedicated screen with new functionality. Together with a new mechanism for add-on developers to extend the gateway’s REST API, this opens up a whole new world of possibilities for add-on developers to customise the gateway. Note that the updated add-ons system comes with a new manifest format inspired by Web Extensions. Stand by for a blog post next week which will explain in more depth how to use the new add-ons system. We’ll walk you through building your own extension add-on. Localisation Settings Many add-ons use location-specific data like weather, sunrise/sunset and tide times, but it’s no fun to have to configure your location for each add-on. It’s now possible to choose your country, time zone and language via the gateway’s web interface. With time zone support, time-based rules should now correctly adjust for daylight savings time in your region. Since the gateway is configured to use Greenwich Mean Time by default, your rules may show times you didn’t expect at first. To fix this, you’ll need to set your time zone appropriately and adjust your rule times. You can also set your preference of unit used to display temperature, to either degrees Celsius or Fahrenheit. And finally, many of you have asked for the user interface to support multiple languages. We are shipping with an Italian translation in this release thanks to our resident Italian speaker Kathy. We already have French, Dutch and Polish translations in the pipeline thanks to our wonderful community. Stand by for more information on how to contribute to translations in your language! API Changes & Standardisation For developers, in addition to the new add-ons system, it’s now possible to communicate with all the gateway’s web things via a single WebSocket connection. Previously it was necessary to open a WebSocket per device, so this is a significant enhancement. We’ve recently started the Web Thing Protocol Community Group at the W3C with the intention of standardising this WebSocket sub-protocol in order to further improve interoperability on the Web of Things. We welcome developers to join this group to contribute to the standardisation process. Coming Soon Coming up next, expect Mycroft voice controls, translations into more languages and new ways to install and use WebThings Gateway. As always, you can head over to the forums for support. And we welcome your contributions on GitHub. The post Thermostats, Locks and Extension Add-ons – WebThings Gateway 0.10 appeared first on Mozilla Hacks - the Web developer blog. [Less]

Highlights The “Omniscient” Browser Toolbox will be enabled by default in the coming days This is a browser developer toolbox with the ability inspect/debug multiple processes As a follow up, the Browser Content Toolbox (which debugs the content ... [More] process of for the current tab) will be no longer needed and removed. The JavaScript Debugger’s new Watchpoints feature, which let you pause on object property get/set, are on by default in Nightly and will ride to DevEdition for more QA and user feedback A watchpoint paused on this.model.attributes.completed being set. The Network Monitor’s new Request Blocking lets you block requests based on matches patterns – it is now enabled by default on Nightly and DevEdition User-Initiated Picture-in-Picture for videos is now enabled by default on macOS and Linux on Nightly! Please test it out, and file bugs against this meta for us to triage. gl also landed a patch to add mute / unmute capability to the player window This is currently preffed off behind media.videocontrols.picture-in-picture.audio-toggle.enabled while we test it Friends of the Firefox team Resolved bugs (excluding employees) Fixed more than one bug Alex Vincent [:WeirdAl] Ben Campbell Christoph Walcher Chujun Lu Florens Verschelde :fvsch Itiel jaril Mustafa Tim Nguyen :ntim New contributors (🌟 = first patch) 🌟 Alex J Garcia updated the DevTools Network Monitor so that the left and right cursor keys no longer change the request selection 🌟 bayyatej.dev, one of our MSU capstone students, updated our Picture-in-Picture code to use JSWindowActors rather than the message manager Christoph Walcher got rid of some dead code in our arrowscrollbox custom element implementation, as well as the MozTextLabel custom element 🌟 James Jahns, one of our MSU capstone students, made the Page Style menu Fission-compatible Mustafa fixed 3 bugs in the DevTools Network Monitor: Fixed a scrolling glitch when the pane is short Fixed a bug where sometimes the JSON section of the Messages tab is empty when inspecting WebSocket traffic Made it so that formatted content in the WebSocket message viewer is prioritized over raw content 🌟 Thomas Kosmas cleaned out some unnecessary code from the autocomplete popup custom element binding Zhao Gang fixed a regression where pretty-printing some source code in the JavaScript Debugger wouldn’t show any user feedback until the processing was complete Project Updates Accessibility High Contrast Mode’s readability “backplate” no longer backplates items with visibility:hidden. This fixes some sites where a backplate was obscuring content. Zoom buttons (+/-) and full-screen button should be labelled in hamburger menu. This fix makes those buttons screen reader accessible. “Use keyboard navigation” in system preferences does not register with Firefox in OSX Catalina. This was broken on macOS 10.15 and is now fixed. Add-ons / Web Extensions Shane landed the first bits of the changes to the webextensions CSP (Bug 1581611, Bug 1587939, Bug 1581609, content script CSP is currently behind the extensions.content_script_csp.enabled and extensions.content_script_csp.report_only prefs), and fixed a bug related to the behavior of the “private browsing” checkbox included in the post install notification (Bug 1581852). Tomislav fixed AddonManagerWebAPI::IsAPIEnabled in Fission out-of-process iframes (Bug 1591736) Mark Striemer moved the about:addons page header, page options, search addons field and global warnings from XUL to HTML (Bug 1545346) Andrea Marchesini is moving secure-proxy experimental APIs into mozilla-central (Bug 1592687, Bug 1592932), and added the third-party state to the request details provided by the webRequest and proxy API events (Bug 1591900) Gijs made sure that Firefox reuses an existing about:preferences tab when the user is opening it from the about:addons page (Bug 1592600) Matt Woodrow fixed webRequest API regression (Bug 1590898, recently regressed by Bug 1583700) Graham extended the browserAction/pageAction onClicked API event to allow extensions to receive “middle-button” mouse clicks and extended the onClicked event details to also include mouse buttons and keyboard modifiers states (Bug 1405031). Thanks Graham for contributing this enhancement! Itiel fixed the alignment of the warnings/errors messages part of the about:addons extensions shortcuts view when the RTL mode is enabled (Bug 1575472). Thanks Itiel for contributing this fix! Trishul fixed a webRequest bug triggered by webRequest API events received for tabs that are already closed (Bug 1447807). Thanks Trishul for looking into it and contributing a fix! Developer Tools Console’s multi-line editor mode now has shortcuts for importing and saving your snippets back files: Ctrl/Cmd-O and Ctrl/Cmd-S . This is based on feedback from users who were used to these shortcuts when using Scratchpad. Contributor Sorin Davidoi optimized the Debugger to use less resources when the tab is in the background. Browser Toolbox’s –jsdebugger for can now be overridden with another Firefox executable that will be used for the Browser Toolbox, so you can run DevTools in an optimized build: ./mach run –jsdebugger $NIGHTLY Fission M4 came and went with 130 or so tests still not enabled. Teams will continue to fix tests while making the Fission enabled browser stable enough for daily use, which is our M5 target. Classified front end work for M5 Some work already finished: Form history Meta tag handling Favicon support MSU student Teja Bayya ported picture in picture to JSWindowActors Gijs fixed Web Channels New Tab Page Getting Discovery Stream working for the de locale. (right now it’s just en-US and en-CA) Turning personalization back on for sponsored content. Some minor UI and UX fixes and some experiments. Password Manager about:logins Minor fixes Web compatibility input.autocomplete support for username/new-password/current-password values eTLD+1/subdomain login suggestions autocomplete support has been polished with one remaining bug being tracked Starting on accompanying context menu UI Login save/capture improvements (in progress) Only prompt to save logins if a login field was modified by the user Show a dismissed login capture doorhanger when a user edits a password field (before submission) Performance Team is focused on investigating the impact of Fission on responsiveness and is working on finishing two meta bugs that track what Talos tests need adjustments and investigate regressions when fission is enabled dthayer is working on making tabswitch fission compatible and modifying the tabswitch test. emalysz made sure that windows do not animate upon restoring a session and has a patch up for review that relies on a cached policy for sandbox construction, which should improve process launch times Gijs limited the number of times certain prefs are accessed when fission is enabled, ensured a remote browser does not read plugin data on the main thread mconley is investigating fission’s impact on talos tests, such as an improvement in session restore when fission is enabled and a regression on tabpaint Performance Tools The profile metadata panel now shows the settings that were used to capture the profile. This helps us see at a glance how a profile was gathered, which can help explain some of the patterns within the profile. There’s a new Track IPC feature (off by default) that can be enabled from the profiler’s capture panel to track async IPC. The parent process appears to be sending quite a few IPC messages here. Example profile of the IPC happening when opening new tabs. Picture-in-Picture Release plan has changed somewhat – we’re now sufficiently confident in the implementation to let the feature ship to Windows in Firefox 71 without slow rollout MSU student Teja Bayya ported the message manager implementation of Picture-in-Picture to JSWindowActors. This is a crucial step in adding Fission compatibility. Not fully Fission compatible yet though. Here’s the meta bug for that work. mstriemer fixed an issue where some event listeners weren’t getting cleaned up automatically mstriemer has patches in progress to resize the player window if the originating video resizes mconley made the toggle and context menu hidden for videos displaying MediaStreams This is a stopgap until this bug is fixed mconley made always-on-top, resizing and aspect ratio locking work for macOS Search and Navigation Search Search configuration modernization (Firefox 72) Search service fixes and cleanups Address Bar Regression fixes: Fixed performance problems when specially crafted strings were typed in the address bar Disabling bookmarks but not history in address bar preferences, caused  bookmarked pages to not be autofilled anymore, even if visited. Now only unvisited bookmarks are ignored. Fixed annoying bug where copying from the urlbar was failing (slow loading pages or canceled downloads) Visual redesign (aka “megabar”, Firefox 73) Temporarily disabled in Nightly, we are working on a new revision of the design, additional feedback on the old revision was not useful. Will re-enable once we are closer to MVP. New one-off buttons flex behavior for small windows Removed some more legacy urlbar code, especially from autocomplete Search Interventions experiment (Firefox 72) Experimental add-on is being worked on. Search Nudges experiment (Firefox 72) Project revised to use the Search Interventions API. User Journey Launched a couple of “Relationship” CFRs in nightly and beta, riding the trains to release Recommend Firefox Send Recommend Send Tab when viewing an article or a recipes website What’s New feature made it to the release channel Investigating user-agent attribution focusing on “Chrome switchers” to show contextual onboarding, e.g., dynamic first-run cards Potentially expanding new-user onboarding cards to show for pre-Skyline profiles with remote messages to current release users [Less]

Notifications. Can you keep count of how many websites or services prompt you daily for permission to send notifications? Can you remember the last time you were thrilled to get one? Earlier this year we decided to reduce the amount of unsolicited ... [More] notification permission prompts people receive as they move around the web using the Firefox browser. We see this as an intrinsic part of Mozilla’s commitment to putting people first when they are online. In preparation, we ran a series of studies and experiments. We wanted to understand how to improve the user experience and reduce annoyance. In response, we’re now making some changes to the workflow for how sites ask users for permission to send them notifications. Firefox will require explicit user interaction on all notification permission prompts, starting in Firefox 72. For the full background story, and details of our analysis and experimentation, please read Restricting Notification Permission Prompts in Firefox. Today, we want to be sure web developers are aware of the upcoming changes and share best practices for these two key scenarios: How to guide the user toward the prompt. How to acknowledge the user changing the permission. We anticipate that some sites will be impacted by changes to the user flow. We suspect that many sites do not yet deal with the latter in their UX design. Let’s briefly walk through these two scenarios: How to guide the user toward the prompt Ideally, sites that want permission to notify or alert a user already guide them through this process. For example, they ask if the person would like to enable notifications for the site and offer a clickable button. document.getElementById("notifications-button").addEventListener("click", () => { Notification.requestPermission().then(setupNotifications); }); Starting with Firefox 72, the notification permission prompt is gated behind a user gesture. We will not deliver prompts on behalf of sites that do not follow the guidance above. Firefox will instantly reject the promise returned by Notification.requestPermission() and PushManager.subscribe(). However, the user will see a small notification permission icon in the address bar. Note that because PushManager.subscribe() requires a ServiceWorkerRegistration, Firefox will carry user-interaction flags through promises that return ServiceWorkerRegistration objects. This enables popular examples to continue to work when called from an event handler. Firefox shows the notification permission icon after a successful prompt. The user can select this icon to make changes to the notification permission. For instance, if they decide to grant the site the permission, or change their preference to no longer receive notifications. How to acknowledge the user changing the permission When the user changes the notification permission through the notification permission icon, this is exposed via the Permissions API: navigator.permissions.query({ name: "notifications" }).then(status => { status.onchange = () => potentiallyUpdateNotificationPermission(status.state); potentiallyUpdateNotificationPermission(status.state); } We believe this improves the user experience and makes it more consistent. And allows to align the site interface with the notification permission. Please note that the code above works in earlier versions of Firefox as well. However, users are unlikely to change the notification permission dynamically in earlier Firefox releases. Why? Because there was no notification permission icon in the address bar. Our studies show that users are more likely to engage with prompts that they’ve interacted with explicitly. We’ve seen that through pre-prompting in the user interface, websites can inform the user of the choice they are making before presenting a prompt. Otherwise, unsolicited prompts are denied in over 99% of cases. We hope these changes will lead to a better user experience for all and better and healthier engagement with notifications. The post Upcoming notification permission changes in Firefox 72 appeared first on Mozilla Hacks - the Web developer blog. [Less]

The Kenyan Data Protection and Privacy Act 2019, was signed into law last week. This GDPR-like law is the first data protection law in Kenyan history, and marks a major step forward in the protection of Kenyans’ privacy. Mozilla applauds the ... [More] Government of Kenya, the National Assembly, and all stakeholders who took part in the making of this historic law. It is indeed a huge milestone that sees Kenya become the latest addition to the list of countries with data protection related laws in place; providing much-needed safeguards to its citizens in the digital era. Strong data protection laws are critical in ensuring that user rights are protected; that companies and governments are compelled to appropriately handle the data that they are entrusted with. As part of its policy work in Africa, Mozilla has been at the forefront in advocating for the new law since 2018. The latest development is most welcome, as Mozilla continues to champion the 5 policy hot-spots that are key to Africa’s digital transformation. Mozilla is pleased to see that the Data Protection Act is consistent with international data protection standards, through its approach to placing users’ rights at the centre of the digital economy. They also applaud the creation of an empowered data protection commission with a high degree of independence from the government. The law also imposes strong obligations placed on data controllers and processors. It requires them to abide by principles of meaningful user consent, collection limitation, purpose limitation, data minimization, and data security. It is commendable that the law has maintained integrity throughout the process, and many of the critical comments Mozilla submitted on the initial Data Protection Bill (2018) have been reflected in the final act. The suggestions included the requirement for robust protections of data subjects with the rights to rectification, erasure of inaccurate data, objection to processing of their data, as well as the right to access, and to be informed of the use of their data; with the aim of providing users with control over their personal data and online experiences. Mozilla continues to be actively engaged in advocating for strong data privacy and  protection in the entire African region, where fewer than 20 countries have a data protection law. Considering that the region has the world’s fastest growth in internet use over the past decade, the continent is poised for great opportunities around accessing the internet. However, without the requisite laws in place, many users, many of whom are accessing the internet for the first time, will be put at risk. The post Mozilla plays role in Kenya’s adoption of crucial data protection law appeared first on Open Policy & Advocacy. [Less]