Mozilla Firefox

In the curl project we produce and ship a rock solid and reliable library for the masses, we must never exit, leak memory or do anything in an ungraceful manner. We must free all resources and error out nicely whatever problem we run into at ... [More] whatever moment in the process. To help us stay true to this, we have a way of testing we call “torture tests”. They’re very effective error path tests. They work like this: Torture tests They require that the code is built with a “debug” option. The debug option adds wrapper functions for a lot of common functions that allocate and free resources, such as malloc, fopen, socket etc. Fallible functions provided by the system curl runs on. Each such wrapper function logs what it does and can optionally either work just like it normally does or if instructed, return an error. When running a torture test, the complete individual test case is first run once, the fallible function log is analyzed to count how many fallible functions this specific test case invoked. Then the script reruns that same test case that number of times and for each iteration it makes another of the fallible functions return error. First make function 1 return an error. Then make function 2 return and error. Then 3, 4, 5 etc all the way through to the total number. Right now, a typical test case uses between 100 and 200 such function calls but some have magnitudes more. The test script that iterates over these failure points also verifies that none of these invokes cause a memory leak or a crash. Very slow Running many torture tests takes a long time. This test method is really effective and finds a lot of issues, but as we have thousands of tests and this iterative approach basically means they all need to run a few hundred times each, completing a full torture test round takes many hours even on the fastest of machines. In the CI, most systems don’t allow jobs to run more than an hour. The net result: the CI jobs only run torture tests on a few selected test cases and virtually no human ever runs the full torture test round due to lack of patience. So most test cases end up never getting “tortured” and therefore we miss out verifying error paths even though we can and we have the tests for it! But what if… It struck me that when running these torture tests on a large amount of tests, a lot of error paths are actually identical to error paths that were already tested and will just be tested again and again in subsequent tests. If I could identify the full code paths that were already tested, we wouldn’t have to test them again. But getting that knowledge would require insights that our test script just doesn’t have and it will be really hard to make portable to even a fraction of the platforms we run and test curl on. Not the most feasible idea. I went with something much simpler. I simply estimate that most test cases actually have many code paths in common with other test cases. By randomly skipping a few iterations on each test, those skipped code paths might still very well be tested in another test. As long as the skipping is random and we do a large number of tests, chances are we cover most paths anyway. I say most because it certainly will not be all. Random skips In my first shot at this (after I had landed to change that allows me to control the torture tests this way) I limited the number of errors to 40 per test case. Now suddenly the CI machines can actually blaze through the test cases at a much higher speed and as a result, they ran torture tests on tests we hadn’t tortured in a long time. I call this option to the runtests.pl script --shallow. Already on this my first attempt in doing this, I struck gold and the script highlighted code paths that would create memory leaks or even crashes! As a direct result of more test cases being tortured, I found and fixed nine independent bugs in curl already before I could land this in the master branch, and there seems to be more failures that pop up after the merge too! The randomness involved may of course delay the detection of some problems. Room for polishing The test script right now uses a fixed random seed so that repeated invokes will make it work exactly the same. Which is good when you want to reproduce it elsewhere. It is bad in the way that each test will have the exact same tests skipped every test round – as long as the set of fallible functions are unmodified. The seed can be set by a command line argument so I imagine a future improvement would be to set the random seed based on the git commit hash at the point where the tests are run, or something. That way, torture tests on subsequent commits would get a different random spread. Alternatively, I will let the CI systems use a true random seed to make it test a different set every time independent of git etc – as when it detects an error the informational output will still be enough for a user to reproduce the problem without the need of a seed. Further, I’ve started out running --shallow=40 (on the Ubuntu version) which is highly unscientific and arbitrary. I will experiment altering this amount both up and down a bit to see what I learn from that. Torture via strace? Another idea that’s been brewing in my head for a while but I haven’t yet actually attempted to do this. The next level of torture testing is probably to run the tests with strace and use its error injection ability, as then we don’t even need to build a debug version of our code and we don’t need to write wrapper code etc. Credits Dice image by Erik Stein from Pixabay [Less]

Webcompat bugs Brian Birtles has a strange issue that he can reproduce only on Japanese Windows with Firefox. We tried on 3 different windows, and it reproduces. But it doesn't reproduce on Windows for Sergiu. Another issue related to user agent ... [More] sniffing, which has a bad consequence for the code. Strange behavior of an anchor, followup the issue and discussion on bugzilla. Known issue about overflow and padding on elements. Google Docs graph in canvas does not have the right resolution. The weird thing is that Firefox seems to return an incoherent value for the device to pixel ratio. Flexbox issue. flex-basis: 100% doesn't resolve the same way in Firefox and Chrome. Usually you are on the safer side, if you use flex-basis: auto instead. Another site, same issue with the addition of using the first webkit version of Flexbox. Basically this site would be falling apart if it was not for the implementation of -webkit- prefixes for flexbox. Sad panda. I haven't cracked down this one yet. The site deviantart is displaying the wrong contextual menu on double click. On minecraft website, there is an infinite resize of the canvas. and it's growing, growing, growing. Outreach Q42019 We decided to try to tackle the pile of issues which needed contacts. Before we had dedicated persons: Adam and myself. But we now kind of switched roles. So without daily love, the piles of needscontact (we need to find a contact) and contactready (we need to actually contact) tends to grow. So this week, I made a special effort specifically on the contactready list. One of my axioms for Webcompat: If you wait long enough, a bug goes away. Indeed. The site disappears, has been redesigned, the libraries have been changed. With Adam, we had determined that if we were doing the full process quickly, we had more chances to catch bugs and solve issues for users. Reality and the volume of incoming bugs make this difficult. Fixing the Web requires a dedicated will from the whole industry to change its practices. Web compatibility issues share some of the aspects of the climate change (except no mass extinction if the Web disappears). This outreach week was a mixed bag of not valid anymore bugs and still ongoing issues. Once contacted, it doesn't mean the issue will be fixed. Note that this process is open to everyone. If you want to help, you are more than welcome. Misc A bit of code review. I'm getting rusty. One week to wrap up the 2019Q4 projects. And to add to my misery of 2 weeks ago, I completely missed the meeting last Tuesday. Not in my calendar, but still a complete slip of mind. I'm glad holidays are coming soon. I probably need a good time resting. Berlin Mozilla All Hands is approaching. Sonia Singla is joining the team during a couple of months to work on UX stuff. She's joining in the context of outreachy. It's very cool to see Kate and Guillaume practically handling the webcompat dashboards by themselves on a week to week basis. They do an awesome job. I have a lot of respect for them and their dedicated attention to details. Plus each time, I had to meet them face to face, it was a lovely time. I know that Kate might be looking for a (remote) job. She is in Italy. Give her a chance. She was previously an outreachy. Otsukare! [Less]

Today, we passed the two thirds mark of this crazy project. It is Sunday, December 15, the third advent. Time to reflect a bit on the number 15, which takes a bit of a special place in my life. I was born on April 15, 1973. The checksum of 15 ... [More] is 6, which is the product of the very first two prime numbers, 2 and 3. 15 itself is the product of the first odd prime numbers, 3 and 5. The checksum of my full birthday is 30, which is the product of 2 and 15, or 2 * (3 * 5). If you break it down to a single digit, you get 3, which again is the first odd prime number. My father is exactly 30 years older than me. My sister is 6 years younger than me, and my mom is six years younger than my father. Yes, my mom and sister are also 30 years apart. And there are two persons participating in each of these comparisons. My wife is exactly 15 months older than me. Her birthday is January 15, 1972. We started dating on May 21, 2011, whose checksum is 3, and got married on December 30, 2013, which again is checksum 3. Two times 3 is again 6, which is again the checksum of our mutual day of birth, the 15, and the number of months we’re apart age-wise. And all of this would not check out if my birth hadn’t been delayed by a day. I was predicted to arrive on the 14th, but decided to wait a day longer to make this all fit. Because that’s how I roll. Oh and this is day 21 in my extended advent calendar. And the checksum of 21 is? [Less]

Firefox 72, currently in beta, received some fixes to the Accessibility Inspector this week. Here they are. The first fix is to a longer standing issue. If you opened Accessibility Inspector by right-clicking an element and choosing Inspect ... [More] Accessibility Properties, keyboard focus would not land on the Inspector or Properties tree view, but in limbo somewhere on the document. You had to tab a couple of times to get focus to the correct place. Well, that will be no more. From now on, keyboard focus will land in the properties tree, so you can directly start exploring the name, role, states etc., of the element you are interested in. Related to that, if you selected to inspect an accessibility element’s property either from the browser or DOM Inspector context menus, the selected row in the Accessible Objects tree would not always scroll to actually show the selected item. That too has been fixed. Moreover, if you’re already following along the betas, you may have noticed that within Accessibility Properties, the thing that was once called DOM Node, and which allows you to quickly jump to the HTML element that created this accessible object, was called “Node Front”. Well, that has also been addressed and will probably soon even be localized. And last, but not least, resulting from direct feedback we received after Firefox 70 was released, if you have an SVG element which is properly labeled at its root, its children elements will no longer be flagged as having no proper label when auditing your site for accessibility problems. If an SVG has a role of “img” and is tagged, that will be sufficient to satisfy the auditing facility. In fact, this change is already in Firefox 72 Beta 5 or newer, whereas the other changes mentioned above will appear in Firefox 72 Beta 7 early next week. Keep the feedback coming! We are constantly fixing bugs and improving the auditing tool to give you better results when testing or developing. [Less]

Home security cameras are in the news (again), featuring startling clips of hackers speaking creepily to children and sleeping adults through Ring cameras inside private homes. Ring says there has … Read more The post Tips to improve your Ring camera security appeared first on The Firefox Frontier.

Home security cameras are in the news (again), featuring startling clips of hackers speaking creepily to children and sleeping adults through Ring cameras inside private homes. Ring says there has … Read more The post Tips to improve your Ring camera security appeared first on The Firefox Frontier.

Today, Mozilla continues the fight to preserve net neutrality protection as a fundamental digital right. Alongside other petitioners in our FCC challenge, Mozilla, Etsy, INCOMPAS, Vimeo and the Ad Hoc Telecom Users Committee filed a petition for ... [More] rehearing and rehearing en banc in response to the D.C. Circuit decision upholding the FCC’s 2018 Order, which repealed safeguards for net neutrality. Our petition asks the original panel of judges or alternatively the full complement of D.C. Circuit judges to reconsider the decision both because it conflicts with D.C. Circuit or Supreme Court precedent and because it involves questions of exceptional importance. Mozilla’s petition focuses on the FCC’s reclassification of broadband as an information service and on the FCC’s failure to properly address competition and market harm. We explain why we believe the Court can in fact overturn the FCC’s new treatment of broadband service despite some of the deciding judges’ belief that Supreme Court precedent prevents rejection of what they consider a nonsensical outcome. In addition, we point out that the Court should have done more than simply criticize the FCC’s assertion that existing antitrust and consumer protection laws are sufficient to address concerns about market harm without engaging in further analysis. We also note inconsistencies in how the FCC handled evidence of market harm, and the Court’s upholding of the FCC’s approach nonetheless. We are excited to continue to lead this effort as part of a broad community pressing for net neutrality protections, and Mozilla supports other petitioners’ filings at this stage that address additional important issues for reconsideration. See below for copies of the petitions filed. Petition for rehearing and rehearing en banc filed by: Mozilla, Etsy, INCOMPAS, Vimeo, and the Ad Hoc Telecom Users Committee New America’s Open Technology Institute, Free Press, Public Knowledge, CDT, The Benton Institute for Broadband & Society, CCIA, and National Association of State Utility Consumer Advocates National Hispanic Media Coalition   The post Petitioning for rehearing in Mozilla v. FCC appeared first on The Mozilla Blog. [Less]

Late in November, I published a personal opinion on the state of Gutenberg accessibility. Today, I’d like to give an introduction to Gutenberg from a screen reader user perspective. Gutenberg, the WordPress block editor, is the new way to ... [More] create content and build sites in WordPress. It is a rich web application that uses many modern techniques such as dynamic updates, toolbars, side bars and other items to completely update the posting experience. It can also be quite daunting at first. Let us try to shed a little light on some of the mysteries around it. It is not mandatory First things first: It is not mandatory yet to use Gutenberg. You can install the Classic Editor plugin, which is fully maintained by the WordPress team for the foreseeable future. Once installed, you change a setting in your user profile to make sure you get the Classic Editor experience. Once you change this, you will have the same well-known WordPress posting experience you’ve always had, with both a plain HTML text and the TinyMCE editor for more rich editing of your post. Once you enable that setting, WordPress will take Gutenberg out of the mix. You will have your post types, categories, tags, and other information where you are used to in your WordPress Admin, Create A New Post interface. A general overview But if you decide to go all in on Gutenberg, here is a general overview. Gutenberg manages the whole posting experience from initial creation to proof-reading, rearranging content, adding categories and tags, adjusting the publishing date, to pressing the big scary Publish button. The interface consists of several more or less static elements as well as one central area that is very dynamic in nature. The top of the editor contains two toolbars. One is labeled the document tools toolbar and contains buttons to insert a new block, undo changes, re-do them, and since Gutenberg 7.0, a toggle under the More Options menu that tells the editor whether it is in selection or editing mode. More on that later. The other toolbar right below that contains options to save, enable or disable the Settings side bar, adjust Jetpack settings, and bring up the publishing panel. Its More Options menu contains items to control various other options, open a dialog with a current set of keyboard shortcuts, etc. This is all pretty standard and works great with a screen reader. Focus is managed correctly when opening and closing menus, etc. Feel free to explore. The other pretty standard item is the side bar. This is located at the very bottom of the virtual buffer, if you are using a screen reader that has one, such as NVDA or JAWS. It shows either the document settings, or the settings for the currently selected paragraph. The document settings is where you set your categories, tags, maybe add a post excerpt, control whether your post can receive comments or trackbacks, etc. The block settings can vary. For paragraphs, you get items for adjusting font size and family, maybe colors, and more. For images, this is where you set the alternative text, among other things. A set of two tabs at the bottom switches between Document and Block settings. One other item that appears here is the Jetpack settings if you select that from the main toolbar, and the Publishing settings. Many items in the Publishing panel are similar to the document settings described above, but if you have Social Media Sharing set up, for example, this is where you adjust your Tweet text for the initial post. These controls are also all pretty standard. The collapsible sections expand or collapse if you press Enter on them, and even items such as the calendar for adjusting the publishing date and time is very accessible. The main block contents The real fun begins in the central editor part. It begins with the post title, and then spans one or multiple blocks you add to your post or page. My workflow, for example, is to type the title, then press Enter. You could also press tab, which will then take you to the Copy Permalink item, and then onto the URL itself, plus into the actual first block. Depending on your version of Gutenberg, after you press Enter after typing the title, the editor places you in either selection or editing mode. In 7 and later, it will default to editing mode, so you can continue typing your text. In 6.9, it will place you on a Paragraph block button. That is selection mode, and you have to press Enter once more to actually enter editing mode and being able to type. Caveat: Sometimes screen readers don’t speak the focus transition here. Best to turn off virtual cursor and check with your ScreenReaderModifier+Tab which item has focus. It should be an Empty Block item. Once you are in the first block, and in editing mode, start typing to simply create a paragraph block. You can use arrow keys to navigate, and if you press Enter, you will create a new, empty block. However, before typing text, you can also change the block type right from the keyboard. Type a forward slash, /, and a popover will open to allow you to select a block type. Start typing some characters, for example h and e for heading. This is an accessible autocomplete, and it will speak the first item it found. You can press up and down arrows to select a different block type, and Enter to accept. The editor will return you to editing mode, but now the screen reader might say something like “Heading block, level 2, editing”. You know that you are going to now type a heading level 2. Finish your sub section title and press Enter to create a new block below. The blocks all have a dynamic toolbar attached to them. Most of that toolbar’s contents only becomes visible to sighted people if text is selected. Then, you can apply formatting such as bold, italic, underline, turn it into a link, etc. But if you opened and studied the shortcut keys above, you’ll know that you can also use keyboard shortcuts like CTRL+B for bold, or CTRL+K for link. However, if you want to access the toolbar, you can always do so from the keyboard by pressing Alt+F10. Yes, if you used TinyMCE before, that’s the same shortcut that brought you into its toolbar system as well. Once the toolbar opens, use left and right arrows to navigate between controls. Escape will bring you back to the text field. In a heading block, for example, you can use the toolbar to change its level from 2 to 3 to 4 etc. There are a few more elements above the current block that are always there, which can either be tabbed or shift-tabbed to once the toolbar is open, or you can turn focus or forms mode off and use the virtual cursor to move upwards into the toolbar. One is a button to change the block type through a dropdown. This comes in handy if you already have text entered and therefore can no longer use the forward slash shortcut. The other two buttons are mover buttons. These move the current block up or down above or below other blocks. In some layouts, you may also have the option to move a block to the right into the next column, or to the left into the previous one. My suggestion for the very dynamic nature of the blocks is to use mostly forms/focus mode in your screen reader to move among blocks. If you are on the first line of a block, and there is another block above it, an Up Arrow will take you into that block. There is a real focus change happening, so the experience is different than if you moved among paragraphs in a Word document, but that’s the quickest way to go from one block to the other. Also, to manipulate a block via the toolbar, use Alt+F10 to bring up the toolbar instead of trying to search for it using the virtual cursor. Edit and Selection Modes As hinted before, Gutenberg knows two modes to operate in. One is Editing mode, which we have covered so far. The other is selection mode. In this mode, you can quickly navigate among blocks. To enter Selection mode, press Escape while editing a block. That will drop you into navigation mode. If you are using a screen reader, you may have to press Escape twice, since the first press might just turn off forms or focus mode and invoke your virtual reading cursor. However, once in Selection mode, I suggest to turn focus mode on by hand and navigate using tab or arrow keys, since that allows navigation among blocks using the native editor keyboard commands. After selecting a different block, press enter to turn Edit Mode back on and return to manipulating text. Version differences WordPress comes with a version of Gutenberg that was available at the time of the release of your particular WordPress version. It gets updated each time WordPress gets updated. However, you can also decide to get on the two week release cycle of Gutenberg itself and therefore be independent from WordPress releases. The advantage is that you get new features and accessibility improvements faster than with a WordPress release. The disadvantage is that, as with any software, sometimes there can be bugs that get introduced and then take another two weeks to fix. Unless, of course, the team decides to put out an emergency fix release. You get onto the two week release cycle by installing the Gutenberg plugin from the WordPress Plugin Repository. Yes, you can install that even though your WordPress already comes with a preinstalled version of Gutenberg. The only exception is if you run your blog on WordPress.com, the hosting service by Automattic, and are on the free, Personal or Premium plans, which don’t allow plugin installations. Then, you’ll always have to wait for Automattic to integrate newer versions of Gutenberg into the WordPress install that you get on WordPress.com. Closing remarks The dynamic nature, and seemingly weird keyboard behavior that results from that, can at times be quite unnerving. It is definitely a challenge to keep track of which mode you are in, which block you are editing, and what options are available. For screen reader users, who have very sequential access to web applications, some of these concepts may be difficult to grasp at first, and definitely incur a steeper learning curve than most sighted users will have with Gutenberg. But mastering it is not impossible. As with any complex web application like Gmail, Google Docs, Slack or the like: Know their shortcuts, know your screen reader and its powers, and you’ll be fine. Let me close by thanking those from the Gutenberg development team who have reached out to me after my last post on the subject and asked for input. Together with the other members of the accessibility team, we’ve had some very good and productive conversations that hopefully will move things forward in interesting ways in the coming months. And I mean that in the most positive sense, without irony or sarcasm. I will post irregular updates on significant changes that make it into new Gutenberg releases. And I’ll hopefully keep this guide updated with new information as it becomes available. Until then, have fun playing with Gutenberg! Hope these tips help you in finding your way around. [Less]

After I watched a talk by Marcus Olsson about docs as code (at foss-sthlm on December 12 2019), I got inspired to provide links on the curl web site to make it easier for users to report bugs on documentation. Starting today, there are two new ... [More] links on the top right side of all libcurl API function call documentation pages. File a bug about this page – takes the user directly to a new issue in the github issue tracker with the title filled in with the name of the function call, and the label preset to ‘documentation’. All there’s left is for the user to actually provide a description of the problem and pressing submit (and yeah, a github account is also required). View man page source – instead takes the user over to browsing that particular man pages’s source file in the github source code repository. Click the image for full resolution version. Since this is also already live on the site, you can also browse the documentation there. Like for example the curl_easy_init man page. If you find mistakes or omissions in the docs – no matter how big or small – feel free to try out these links! Credits Image by Pexels from Pixabay [Less]

Hello everyone, We have an important announcement to make today, regarding the future of the Testday and Bugday community events we have been holding for our desktop product. The state of things QMO events have been around for several years now, with ... [More] many loyal Mozilla contributors engaged in various types of manual testing activities– some centered around verification of bug fixes, others on trying out exciting new features or significant changes made to the browser’s core ones. The feedback we received through them, during the Nightly and Beta phases, helped us ship polished products with each iteration, and it’s something that we’re very grateful for. We also feel that we could do more with the Testday and Bugday events. Their format has remained unchanged since we introduced them and the lack of a fresh new take on these events is now more noticeable than ever, as the overall interest in them has been dialing down for the past couple of years. We think it’s time to take a step back, review things and think about new ways to engage the community going forward. Goodbye, for now Starting 2020, we are going to take some time to figure out what our next plans are. Test Days and Bugdays will be paused as a result, but we do plan to hold a final Testday this year, on December 20– we hope to see all of you there! As we move forward, the #qa IRC channel will remain the best way to connect with us, so don’t hesitate to drop by and say hi. You’ll still be able to contribute towards bug fix verification by looking at bugs with the [good first verify] keyword. Thank you all for your passion, loyalty and dedication to Firefox! As always, it’s inspiring to work with such amazing people! [Less]