Mozilla Firefox

Have you heard of Blue Beanie Day before? Well, I have, but only because I have been involved with web standards and accessibility for so long. The Cute Calendar has all information. And you know what? I even know a few people who celebrate it. ... [More] This year, I’ve heard of Deborah and Jeffrey celebrating it. Do you celebrate it, too? Let us all know in the comments! [Less]

The end of the 2019Q4 is approaching at the speed of light, specifically for me, given that I will be away starting December 21 until January 2. Previous instance of the week notes has been published. Webcompat Team The reassignment of Thomas to the ... [More] Gecko View team for 6 months (wonderful for him), will probably make all of that a bit harder for the full Webcompat team, because he is that good. The curve of needsdiagnosis is starting again to rise dangerously. Having clear and shared understanding of the scope of a project help to work more harmoniously across teams. Next project, I will shake the tree until we have a clear understanding of what we are trying to do with a plan for execution with clear criteria and exit strategy. Also every stakeholders need to be included. It must be frustrating for every parties on both side of the issues. Not that any opinions is more valid than the other, but the agreement is not clearly defined and embraced. Mozilla Participated to an online course on "(Staff) Community Participation Guidelines ("CPG") Enforcement", which I will summarize as a solid framework to handle any threats. Improving the Firefox devtools is a daily quest. This week. Allow to set breakpoint on prettified inline scripts. Pause the debugger while the browser is focused Break on attribute modification when style attributes are changed long names for scripts breaks the debugger tool layout This week-end participating to JS Conf Tokyo Webcompat.com Mike had to refine a bit the rules for CERT on webcompat.com, to allow the validity of www.webcompat.com. Kate (volunteer contributor 🙇🏼) proposed a transition plan to black on the metrics server code. Fixed webcompat-to-bugzilla extension. It was adding a leading space to URL string, and bugzilla was not happy about it. Webcompat Bugs if someone knows which framework adds this doNotShowUnsupportedBrowserModal in the JavaScript of some websites, tell me. I would be interested to get their framework fixed. Right now we have to rely on site interventions to remove the useless messages. some JavaScript apps are just huge. BMO has an app.js file for mobile devices which is 2.0 MB and around 332947 lines of code once prettified. And this is not the only material in there. The total is 22.3 MB. Strange issue about scrollbars and overflows. Ksenia found the right viewport Viewport issue for this bug. But there was something more which was not right. It seems that user-scalable is not enforced by Chrome on mobile if width=device-width is also not present. They fall back to a viewport of 980px. Obscure combination of line-height, display: contents and font-size. So many ways to break a Web page. Daniel was able to make a test case and filed a bug. For a couple of years some sites break because of zoom, a non-standard property, implemented in WebKit/Trident/Blink worlds but not Gecko. A zoom hack is being experimented. This created a regression in one site at least. There is more to write about that. Personal failure of the week, the quarter? So when coding the prototype for saving the images locally, I started to surface a lot of dependencies, constraints and I start to think that the initial idea was probably better, aka sending the images to S3. I'm not yet 100% confident about it. Both solutions seem simple on paper in principles, but a lot of small subtleties come into play. I should have started to produce code before, but I wanted to explore the topic before hand. I'm still trying in the remaining 3 weeks. And we will see how far I go. One part of the issue was probably my lack of knowledge of Amazon S3. When working on a project, there is a cultural part which is difficult to assess at first. Basically we need to learn. I wish there was an easier way to test these services. I will probably try moto as a standalone server. Reading Contract for the Web Everyone has a role to play in safeguarding the future of the Web ViolaWWW, one of the earliest browsers, source code is available. another way of not running the tests for particular circumstances. A library that allows you to easily mock out tests based on AWS infrastructure. An introduction to boto S3 Contract For The Web Mozilla and the contract for the Web. I have basically the same position than Mozilla on this. I completely adhere to the contract, but I will not sign it. a written or spoken agreement, especially one concerning employment, sales, or tenancy, that is intended to be enforceable by law The issue here is that some of the signatories are currently not credible at all. Facebook, Twitter, Google, etc. That would be different if there was a plan laid out by each of these companies how they would plan to enforce this contract for the Web. Otsukare! [Less]

CSS zoom is a non-standard feature. It was initially implemented by Microsoft Internet Explorer, then was reversed engineered by Apple Safari team for WebKit, and exist in Google Chrome on Blink. Chris talks briefly about the origin. Back in the ... [More] days of IE6, zoom was used primarily as a hack. Many of the rendering bugs in both IE6 and IE7 could be fixed using zoom. As an example, display: inline-block didn't work very well in IE6/7. Setting zoom: 1 fixed the problem. The bug had to do with how IE rendered its layout. Setting zoom: 1 turned on an internal property called hasLayout, which fixed the problem. In Apple docs: Children of elements with the zoom property do not inherit the property, but they are affected by it. The default value of the zoom property is normal, which is equivalent to a percentage value of 100% or a floating-point value of 1.0. Changes to this property can be animated. There is no specification describing how it is working apart of the C++ code of WebKit and Blink. It predates the existence of CSS transforms, which is the right way of doing it. But evidently, the model is not exactly the same. Firefox (Gecko) doesn't implement it. There is a very old open bug on Bugzilla about implementing CSS Zoom, time to time, we duplicate webcompat issues against it. Less often now than previously. On the webcompat side, the fix we recommend to websites is to use CSS transform. A site which would have for example: section {zoom: 1} could replace this with section { transform-origin: 0 0; transform: scale(100%) } And that would do the trick most of the time. On October 2019, Emilio made an experiment trying to implement CSS zoom using only CSS transform, on the same model that the webcompat team is recommending. And we tested this for a couple of weeks in Nightly Firefox 72 until… it created multiple regressions such as this one. After removing the rest of the rules, this the core of the issue: .modal.modal--show .modal-container { transform: translate(-50%,-50%); zoom: 1; } so the fix would replace this by: .modal.modal--show .modal-container { transform: translate(-50%,-50%); transform-origin: 0 0; transform: scale(100%) } hence cancelling the previous rule translate(-50%,-50%) and breaking the layout. Emilio had to disable the preference and we need to think a better way of doing it. Otsukare! [Less]

I’ve known for a while how to override bash builtins, but it was something I’d long filed under “ok but why” in my mental repository of software esoterica. Until I saw this comment I hadn’t considered how useful it could be. I’ve long held the ... [More] position that our tools are so often ahumanist junk because we’re so deeply beholden to a history we don’t understand, and in my limited experience with the various DevOps toolchains, they definitely feel like Stockholm Spectrum products of that particular zeitgeist.  It’s a longstanding gripe I’ve got with that entire class of tools, Docker, Vagrant and the like; how narrow their notions of a “working development environment” are. Source, dependencies, deploy scripts and some operational context, great, but… not much else? And on one hand: that’s definitely not nothing. But on the other … that’s all, really? It works, for sure, but it still seems like a failure of imagination that solving the Works On My Machine problem involves turning it inside out so that “deploy from my machine” means “my machine is now thoroughly constrained”. Seems like a long road around to where we started out but it was a discipline then, not a toolchain. And while I fully support turning human processes into shell scripts wherever possible (and checklists whenever not), having no slot in the process for compartmentalized idiosyncracy seems like an empty-net miss on the social ergonomics front; improvements in tooling, practice or personal learning all stay personal, their costs and benefits locked on local machines, leaving the burden of sharing the most human-proximate part of the developer experience on the already-burdened human, a forest you can never see past the trees. This gist is a baby step in a different direction, one of those little tweaks I wish I’d put together 20 years ago; per-project shell history for everything under ~/src/ as a posix-shell default. It’s still limited to personal utility, but at least it gives me a way to check back into projects I haven’t touched in a while and remind myself what I was doing. A way, he said cleverly, of not losing track of my history. The next obvious step for an idea like this from a tool and ergonomics perspective is to make containerized shell history an (opt-in, obvs) part of a project’s telemetry; I am willing to bet that with a decent corpus, even basic tools like grep and sort -n could draw you a straight line from “what people are trying to do in my project” to “where is my documentation incorrect, inadequate or nonexistent”, not to mention “what are my blind spots” and “how do I decide what to built or automate next”. But setting that aside, or at least kicking that can down the road to this mythical day where I have a lot of spare time to think about it, this is unreasonably useful for me as it is and maybe you’ll find it useful as well. [Less]

I’ve known for a while how to override bash builtins, but it was something I’d long filed under “ok but why” in my mental repository of software esoterica. Until I saw this comment I hadn’t considered how useful it could be. I’ve long held the ... [More] position that our tools are so often ahumanist junk because we’re so deeply beholden to a history we don’t understand, and in my limited experience with the various DevOps toolchains, they definitely feel like Stockholm Spectrum products of that particular zeitgeist.  It’s a longstanding gripe I’ve got with that entire class of tools, Docker, Vagrant and the like; how narrow their notions of a “working development environment” are. Source, dependencies, deploy scripts and some operational context, great, but… not much else? And on one hand: that’s definitely not nothing. But on the other … that’s all, really? It works, for sure, but it still seems like a failure of imagination that solving the Works On My Machine problem involves turning it inside out so that “deploy from my machine” means “my machine is now thoroughly constrained”. Seems like a long road around to where we started out but it was a discipline then, not a toolchain. And while I fully support turning human processes into shell scripts wherever possible (and checklists whenever not), having no slot in the process for compartmentalized idiosyncracy seems like an empty-net miss on the social ergonomics front; improvements in tooling, practice or personal learning all stay personal, their costs and benefits locked on local machines, leaving the burden of sharing the most human-proximate part of the developer experience on the already-burdened human, a forest you can never see past the trees. This gist is a baby step in a different direction, one of those little tweaks I wish I’d put together 20 years ago; per-project shell history for everything under ~/src/ as a posix-shell default. It’s still limited to personal utility, but at least it gives me a way to check back into projects I haven’t touched in a while and remind myself what I was doing. A way, he said cleverly, of not losing track of my history. The next obvious step for an idea like this from a tool and ergonomics perspective is to make containerized shell history an (opt-in, obvs) part of a project’s telemetry; I am willing to bet that with a decent corpus, even basic tools like grep and sort -n could draw you a straight line from “what people are trying to do in my project” to “where is my documentation incorrect, inadequate or nonexistent”, not to mention “what are my blind spots” and “how do I decide what to built or automate next”. But setting that aside, or at least kicking that can down the road to this mythical day where I have a lot of spare time to think about it, this is unreasonably useful for me as it is and maybe you’ll find it useful as well. [Less]

Since its debut in Firefox 61, the Accessibility Inspector in the Firefox Developer Tools has evolved from a low-level tool showing the accessibility structure of a page. In Firefox 70, the Inspector has become an auditing facility to help identify ... [More] and fix many common mistakes and practices that reduce site accessibility. In this post, I will offer an overview of what is available in this latest release. Inspecting the Accessibility Tree First, select the Accessibility Inspector from the Developer Toolbox. Turn on the accessibility engine by clicking “Turn On Accessibility Features.” You’ll see a full representation of the current foreground tab as assistive technologies see it. The left pane shows the hierarchy of accessible objects. When you select an element there, the right pane fills to show the common properties of the selected object such as name, role, states, description, and more. To learn more about how the accessibility tree informs assistive technologies, read this post by Hidde de Vries. The DOM Node property is a special case. You can double-click or press ENTER to jump straight to the element in the Page Inspector that generates a specific accessible object. Likewise, when the accessibility engine is enabled, open the context menu of any HTML element in the Page Inspector to inspect any associated accessible object. Note that not all DOM elements have an accessible object. Firefox will filter out elements that assistive technologies do not need. Thus, the accessibility tree is always a subset of the DOM tree. In addition to the above functionality, the inspector will also display any issues that the selected object might have. We will discuss these in more detail below. The accessibility tree refers to the full tree generated from the HTML, JavaScript, and certain bits of CSS from the web site or application. However, to find issues more easily, you can filter the left pane to only show elements with current accessibility issues. Finding Accessibility Problems To filter the tree, select one of the auditing filters from the “Check for issues” drop-down in the toolbar at the top of the inspector window. Firefox will then reduce the left pane to the problems in your selected category or categories. The items in the drop-down are check boxes — you can check for both text labels and focus issues. Alternatively, you can run all the checks at once if you wish. Or, return the tree to its full state by selecting None. Once you select an item from the list of problems, the right pane fills with more detailed information. This includes an MDN link to explain more about the issue, along with suggestions for fixing the problem. You can go into the page inspector and apply changes temporarily to see immediate results in the accessibility inspector. Firefox will update Accessibility information dynamically as you make changes in the page inspector. You gain instant feedback on whether your approach will solve the problem. Text labels Since Firefox 69, you have the ability to filter the list of accessibility objectss to only display those that are not properly labeled. In accessibility jargon, these are items that have no names. The name is the primary source of information that assistive technologies, such as screen readers, use to inform a user about what a particular element does. For example, a proper button label informs the user what action will occur when the button is activated. The check for text labels goes through the whole document and flags all the issues it knows about. Among other things, it finds missing alt-text (alternative text) on images, missing titles on iframes or embeds, missing labels for form elements such as inputs or selects, and missing text in a heading element. Check for Keyboard issues Keyboard navigation and visual focus are common sources of accessibility issues for various types of users. To help debug these more easily, Firefox 70 contains a checker for many common keyboard and focus problems. This auditing tool detects elements that are actionable or have interactive semantics. It can also detect if focus styling has been applied. However, there is high variability in the way controls are styled. In some cases, this results in false positives. If possible, we would like to hear from you about these false positives, with an example that we can reproduce. For more information about focus problems and how to fix them, don’t miss Hidde’s post on indicating focus. Contrast Firefox includes a full-page color contrast checker that checks for all three types of color contrast issues identified by the Web Content Accessibility Guidelines 2.1 (WCAG 2.1): Does normal text on background meet the minimum requirement of 4.5:1 contrast ratio? Does the heading, or more generally, does large-scale, text on background meet the 3:1 contrast ratio requirement? Will interactive elements and graphical elements meet a minimum ratio of 3:1 (added in WCAG 2.1)? In addition, the color contrast checker provides information on the triple-A success criteria contrast ratio. You can see immediately whether your page meets this advanced standard. Are you using a gradient background or a background with other forms of varying colors? In this case, the contrast checker (and accessibility element picker) indicates which parts of the gradient meet the minimum requirements for color contrast ratios. Color Vision Deficiency Simulator Firefox 70 contains a new tool that simulates seven types of color vision deficiencies, a.k.a. color blindness. It shows a close approximation of how a person with one of these conditions would see your page. In addition, it informs you if you’ve colored something that would not be viewable by a colorblind user. Have you provided an alternative? For example, someone who has Protanomaly (low red) or Protanopia (no red) color perception would be unable to view an error message colored in red. As with all vision deficiencies, no two users have exactly the same perception. The low red, low green, low blue, no red, no green, and no blue deficiencies are genetic and affect about 8 percent of men, and 0.5 percent of women worldwide. However, contrast sensitivity loss is usually caused by other kinds of mutations to the retina. These may be age-related, caused by an injury, or via genetic predisposition. Note: The color vision deficiency simulator is only available if you have WebRender enabled. If it isn’t enabled by default, you can toggle the gfx.webrender.all property to True in about:config. Quick auditing with the accessibility picker As a mouse user, you can also quickly audit elements on your page using the accessibility picker. Like the DOM element picker, it highlights the element you selected and displays its properties. Additionally, as you hover the mouse over elements, Firefox displays an information bar that shows the name, role, and states, as well as color contrast ratio for the element you picked. First, click the Accessibility Picker icon. Then click on an element to show its properties. Want to quickly check multiple elements in rapid succession? Click the picker, then hold the shift key to click on multiple items one after another to view their properties. In Conclusion Since its release back in June 2018, the Accessibility Inspector has become a valuable helper in identifying many common accessibility issues. You can rely on it to assist in designing your color palette. Use it to ensure you always offer good contrast and color choices. We build a11y features into the DevTools that you’ve come to depend on, so you do not need to download or search for external services or extensions first. This blog post is a reprint of my post on Mozilla Hacks, first published on October 29, 2019. [Less]

This morning I merged pull-request #4651 into the curl repository and it happened to then become the 25000th commit. The first ever public release of curl was uploaded on March 20, 1998. 7924 days ago. 3.15 commits per day on average since ... [More] inception. These 25000 commits have been authored by 751 different persons. Through the years, 47 of these 751 authors have ever authored 10 commits or more within a single year. In fact, the largest number of people that did 10 commits or more within a single year is 13 that happened in both 2014 and 2017. 19 of the 751 authors did ten or more changes in more than one calendar year. 5 of the authors have done ten or more changes during ten or more years. I wrote a total of 14273 of the 25000 commits. 57%. Hooray for all of us! (Yes of course 25000 commits is a totally meaningless number in itself, it just happened to be round and nice and serves as a good opportunity to celebrate and reflect over things!) [Less]

(“This Week in Glean” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean. You can ... [More] find an index of all TWiG posts online.) Last week's blog post: This Week in Glean: Glean in Private by chutten. Currently my team is responsible for the Telemetry framework inside Firefox on Desktop and also the Glean SDK, targeting our mobile products. We're working on bringing the Glean experience to Firefox on Desktop, but in the meantime Telemetry is what we have, need to support and sometimes implement new features on. One of these features is a new ping (or, better, a change in a ping), that we now want to support across all our products. I'm speaking of the deletion-request ping here. When a user opts out of Telemetry we take this as a signal to also delete associated data from our pipeline. Implementation in Firefox Desktop was merely renaming an existing ping that is triggered when the user disables "Data Collection and Use" (about:preferences -> Privacy & Security). It contains no additional data. Implementation in Glean was not much harder either. Glean already supports custom pings: Pings that can be defined and send by the application using Glean. Glean's internal pings follow the same pattern, they are just pre-defined. The biggest difference? It's called deletion_request ping instead. On ingestion data from a ping is decoded from its JSON form and put into tables on BigQuery (in our documentation you can find an overview of the data pipeline if you are interested). BigQuery table names can only contain alphanumeric characters and underscores (see "Table naming" in the BigQuery documentation). We avoid any translation in the pipeline by just enforcing this directly on ping names. Glean also enforces the payload schema of pings. Glean itself controls portion of the data, including a sequence number, date field and a bit of metadata about the application its running in (see the ping sections). The rest of the payload consists of metrics as defined by users of Glean. While implementing the new ping I stumbled upon another small detail of Glean: Pings won't be sent out if they would not contain any metrics. And our new ping, by design, should not contain any metrics! We don't want to change this for other pings, so I had to introduce a new flag now: sendIfEmpty (PR #139). That way we can allow the deletion_request ping to be sent without any metrics in there, only containing the basic information. The implementation of the new ping is now done and currently waiting for data review (PR #526). I hope to land this early next week. [Less]

Mozilla supports the Contract for the Web and the vision of the world it seeks to create. We participated in helping develop the content of the principles in the Contract. The result is language very much aligned with Mozilla, and including words ... [More] that in many cases echo our Manifesto. Mozilla works to build momentum behind these ideas, as well as building products and programs that help make them real. At the same time, we would like to see a clear method for accountability as part of the signatory process, particularly since some of the big tech platforms are high profile signatories. This gives more power to the commitment made by signatories to uphold the Contract about privacy, trust and ensuring the web supports the best in humanity. We decided not to sign the Contract but would consider doing so if stronger accountability measures are added. In the meantime, we continue Mozilla’s work, which remains strongly aligned with the substance of the Contract. The post Mozilla and the Contract for the Web appeared first on The Mozilla Blog. [Less]

Firefox toolbars got a significant improvement to keyboard navigability in version 67. It was once again enhanced in Firefox 70. Here’s how. For a long time, Firefox toolbars were not keyboard accessible. You could put focus in the address ... [More] bar, and tab to the search box when it was still enabled by default. But the next press of the tab key would take you to the document. Shift-tabbing from the address bar would take you to the Site Identity button, AKA the Lock icon, and another Shift+Tab would take you to the open tabs. In 2018, we set out to come up with a new model to make this more accessible, and every item reachable via the keyboard. The goal was to make the navigation both efficient and be as close to the toolbar design pattern as possible. Here’s how it now works: Tab and Shift+Tab will move to the next or previous container block or text field. When in a container block, left and right arrows will move to the previous and next toolbar item. Press Enter or Space to activate. In Firefox 70, Jamie made the navigation even faster by adding an incremental search to the whole toolbar system. The only prerequisite is that you are not currently focused on the address bar or a search or other edit control. For example, do the following: From your web page, press Ctrl+L or Alt+D to focus the address field. Press Tab once to get out of the address field onto the first button in the next container. Hit the letter F once or multiple times. Observe or listen as focus moves between all buttons whose tooltip or label start with F, like Firefox Accounts, Firefox menu, Facebook Account Containers (if you have that add-on installed), etc. Instead, if you type the letters f and i in rapid succession, you will land on the first item whose label or tooltip starts with fi, so Firefox Accounts, Firefox menu, but not Facebook Account Containers. This also works with numbers, so if you have the 1Password extension installed, and type the alphanumeric number 1, you’ll jump straight to the 1Password button, no matter where in the various toolbars it is. Cool, ey? Happy surfing! [Less]