Mozilla Firefox

release tag the following changes have been pushed to bugzilla.mozilla.org: [1418205] Update easy product selector on Browse and Enter Bug pages [1379607] Reimplement Google Analytics on bugzilla.mozilla.org [1393950] Block users from signing into ... [More] Phabricator unless they have MFA enabled [1363889] Update BMO to use new Mozilla branding [1420300] Move bug tagging tool from global footer to bug footer [1420295] Remove the Bugzilla version number from homepage [1381296] Buttons on modal UI are not displayed in Fira Sans font, too small compared to other ones [1417980] Fix non-HTTPS links and outdated links where possible discuss these changes on mozilla.tools.bmo. [Less]

It’s not often I get to invite artists and developers to collaborate together so I’m excited to see how they respond to the Reality Redrawn Challenge from Mozilla which launches today. The boundaries between truth and fiction are becoming harder to ... [More] define, in part because of the proliferation of fake news and other forms of misinformation. Mozilla wants to shed light on this by sponsoring public demonstrations, using mixed reality and other art media that make the power of misinformation and its potential impacts visible and visceral. We live in strange times in which legitimate news organizations such as CNN have to launch advertising campaigns to remind people what real information is. Meanwhile social networks that connect millions more people struggle to help them differentiate truth from fiction and to define their unplanned role as media platforms. Throughout historic moments of upheaval people have used art to make sense of what appears to be dystopian reality. The west side of the Berlin wall became one of the largest canvases in the world as Berliners attempted to make sense of their divided city, while the east side remained blank as none were allowed to get close enough to paint. I also like to remember that Jazz icon and civil rights activist Nina Simone set an enduring challenge to all artists when she asked “how can you be an artist and not reflect the times?” Mixed reality includes all the ways in which 3D virtual content can be integrated with someone’s perception of the physical world around them, from simple enhancements of everyday experiences with augmented reality to completely synthesized immersive virtual reality worlds, and all variations in between. You can read more about Mozilla’s contribution to the space here. For this challenge, traditional as well as digital and mixed media artists are invited to submit applications for three levels of financial support. One semi finalist will receive $15,000. Two will receive $7,500 each and two more will receive $5,000 each. Submissions can be made from anywhere in the world on the challenge website. Judging will begin on January 3 and finish on January 15 2018. After the winners are announced they will have three months in which to complete their work. We’re excited to partner with The Tech Museum of Innovation in San Jose where the winners’ work will then be exhibited. The Tech’s landmark building welcomes more than 500,000 visitors a year with 135,000 square feet of exhibits and activities that empower people to use technology to solve problems. The Reality Redrawn Challenge is part of the Mozilla Information Trust Initiative announced August 8 to build a movement to fight misinformation online. The initiative aims to stimulate work towards this goal on products, research, literacy and creative interventions. Today’s announcement marks the first effort within the creative space. I am excited to see how artists respond to the crisis of truth that is infecting more and more people’s experience of the web. The post Woke up and thought you were in a different reality? Reality Redrawn Challenge launches with a total prize value of $40,000 appeared first on The Mozilla Blog. [Less]

You may have found your way to this blog because Mozilla just announced a new challenge with Sketchfab models, or maybe you just want a way to use glTF (GL Transmission Format) models in your A-Frame application. Either way we’ve got you covered. In ... [More] this post I’ll show you how to load a glTF model into an A-Frame application, and some tips on how to modify it to create a fully interactive VR experience. Building a simple scene A-Frame is the easiest way to build VR content on the Web. With just some HTML and a little bit of JavaScript you can build games, interactive demos, and immersive experiences. Create your first simple A-Frame scene by pasting the following code into a new file called scene.html: In this code you will see a bunch of strange looking elements with names like a-scene and a-box. These are the A-Frame elements. Each element has attributes for setting the position, rotation, color, and other properties of the element. Now load this page into your web browser. I would be remiss if I didn’t mention that the newest release of Firefox, Firefox Quantum, has excellent support for 3D and VR. You should see a simple scene that looks like this: Now remove the cube, sphere, and cylinder lines, leaving just the plane. Next, go find a model on Sketchfab that you want to use. All of the models for the WebVR Medieval Fantasy Experience Challenge should use assets from the previous Real-Time Design Challenge and are tagged with medievalfantasyscene. I’ve chosen one called Mega Scene by VitSh. Click the Download (Free) link and choose the DOWNLOAD GLTF option (not the original Blender or FXB model). You will need to create a free Sketchfab account to download it. Your browser will download a ZIP file. Put the ZIP file somewhere near your scene.html file and extract the ZIP file. Open the code to scene.html and add a link to the scene.gltf file using the a-gltf-model element like this. You should see a scene similar to this one: Now you can move it around by adding position and rotation attributes, or change the lighting with some a-light elements. See the A-Frame docs for more details. Note: if you don’t see the model, check in the JavaScript console. Some operating systems set the file permissions of downloads to be readable only by the current user. On my Mac, this created an HTTP 401 error on my local webserver. I had to change the permission to world-readable to be able to view the scene. For more information about the gltl-model component see the documentation page. Subsetting Scenes The scene above looks cool, but to create your own experience you will probably want to use only certain elements from the scene, not everything. A-Frame works in terms of models, so if we want to use just part of it we need to subset the model. There are a few ways to do this. If the designer of the original scene has extracted models from the scene, you can just download those directly. Many of the designers on Sketchfab have already done so. Check the main model description for links, or look at galleries owned by the original designer. For example, the imp from Baba Yaga’s hut is available here. Many of the models have also been tagged with medievalfantasyassets. If the particular scene model you wish to load was marked with individual parts, you can also use the gltf-part component to load only a portion of it. You may need to open the .gltf file to find these names. The file is just JSON, so search for properties called name. Finally, if you are brave, you can download the open-source 3D-editor tool Blender for free to edit and subset the original designs directly. You will also need to install a glTF exporter such as this one from the Khronos Group, or this one from Kupoman. Supporting Assets 3D models are the core of a VR scene, but to create a complete experience you’ll probably want some particle effects, animation, and even audio. The wonderful A-Frame community has built many supplemental components you can use in your application. One of my personal favorites is Diego Goberna’s environment component which can randomly generate terrain, objects, and skyboxes for you. For particles you can use IdeaSpace VR’s particle-system-component and for simple physics you can try out Don McCurdy’s physics component. A-Frame has built-in support for positional audio, but you still need to provide your own audio files. You can find lots of natural sound effects at freesound, and the Free Music Archive has lots of creative commons-licensed music. You can even find background music designed to loop. Always remember to credit the original author of any assets you use in your creation. Next Steps I hope this post gives you a good start at creating cool VR content. If you run into any challenges, feel free to reach out for help. The main A-Frame community lives on the Slack group. We have created a Slack channel specifically for the challenge. You can also read the A-Frame blog for inspiration by seeing what other A-Frame developers have created. And of course use the aframe tag on Stack Overflow. Happy Coding! [Less]

You may have found your way to this blog because Mozilla just announced a new challenge with Sketchfab models, or maybe you just want a way to use GLTF (GL Transmission Format) models in your A-Frame application. Either way we’ve got you covered. In ... [More] this post I’ll show you how to load a GLTF model into an A-Frame application, and some tips on how to modify it to create a fully interactive VR experience. Building a simple scene A-Frame is the easiest way to build VR content on the Web. With just some HTML and a little bit of JavaScript you can build games, interactive demos, and immersive experiences. Create your first simple A-Frame scene by pasting the following code into a new file called scene.html: In this code you will see a bunch of strange looking elements with names like a-scene and a-box. These are the A-Frame elements. Each element has attributes for setting the position, rotation, color, and other properties of the element. Now load this page into your web browser. I would be remiss if I didn’t mention that the newest release of Firefox, Firefox Quantum, has excellent support for 3D and VR. You should see a simple scene that looks like this: Now remove the cube, sphere, and cylinder lines, leaving just the plane. Next, go find a model on Sketchfab that you want to use. All of the models for the WebVR Medieval Fantasy Experience Challenge should use assets from the previous Real Time Design Challenge and are tagged with medievalfantasyscene. I’ve chosen this one called Mega Scene by VitSh. Click the Download (Free) link and choose the DOWNLOAD GLTF option (not the original Blender or FXB model). You will need to create a free SketchFab account to download it. Your browser will download a zip file. Put the zip somewhere near your scene.html file and unzip it. Open the code to scene.html and add a link to the scene.gltf file using the a-gltf-model element like this. You should see a scene similar to this one: Now you can move it around by adding position and rotation attributes, or change the lighting with some a-light elements. See the A-Frame docs for more details. Note: if you don’t see the model check in the JavaScript console. Some operating systems set the file permissions of downloads to be readable only by the current user. On my Mac, this created an HTTP 401 error on my local webserver. I had to change the permission to world-readable to be able to view the scene. For more information about the gltl-model component see the documentation page. Subsetting Scenes The scene above looks cool, but to create your own experience you will probably want to use only certain elements from the scene, not everything. A-Frame works in terms of models, so if we want to use just part of it we need to subset the model. There are a few ways to do this. If the designer of the original scene has extracted models from the scene, you can just download those directly. Many of the designers on SketchFab have already done so. Check the main model description for links, or look at galleries owned by the original designer. For example, the imp from Baba Yaga’s hut is available here. Many of the models have also been tagged with medievalfantasyassets. If the particular scene model you wish to load was marked with individual parts, you can also use the gltf-part component to load just a portion of it. You may need to open the .gltf file to find these names. The file is just JSON, so search for properties called name. Finally, if you are brave, you can download the open source 3D editor tool Blender for free to edit and subset the original designs directly. You will also need to install a GLTF exporter such as this one from the Khronos Group, or this one from Kupoman. Supporting Assets 3D models are the core of a VR scene, but to create a complete experience you’ll probably want some particle effects, animation, and even audio. The wonderful A-Frame community has built many supplemental components you can use in your application. One of my personal favorites is Diego Goberna’s environment component which can randomly generate terrain, objects, and skyboxes for you. For particles you can use IdeaSpace VR’s particle-system-component and for simple physics you can try out Don McCurdy’s physics component. A-Frame has built in support for positional audio, but you still need to provide your own audio files. You can find lots of natural sound effects at freesound and the Free Music Archive has lots of creative commons licensed music. You can even find background music designed to loop. Always remember to credit the original author of any assets you use in your creation. Next Steps I hope this post gives you a good start at creating cool VR content. If you run into any challenges, feel free to reach out for help. The main A-Frame community lives on the Slack group. We have created a Slack channel specifically for the challenge. You can also read the A-Frame blog for inspiration by seeing what other A-Frame developers have created. And of course use the aframe tag on Stack Overflow. Happy Coding! [Less]

I’m excited to announce Off-Main-Thread painting, our new Firefox graphics performance effort! It’s shipping soon in our next release, Firefox 58 – directly on the heels of Advanced Layers, our new compositor for Firefox 57. To understand OMTP, and ... [More] why it’s a big deal for us, it helps to understand how Firefox renders a webpage down to pixels on your screen. There are four main steps involved: Making a Display List: Here we collect the visible elements on the page and create high-level primitives to encapsulate rendering each one. These primitives are called “display items.” Assigning Layers: Here we try to group display items together into “layers”, based on how they are scrolled or animated. There are different types of layers. Display items will usually be grouped into “Painted” layers, which have a texture (or bitmap) that is updated when items are added, removed, or changed. Rasterization: This is where each display item is asked to render itself into its assigned layer. For example, a “table” item might issue a series of API calls to draw borders and lines. Compositing: Finally, the layers are composited into a single final image, which is then sent to the monitor. This step uses Direct3D or OpenGL when available. These steps occur across two threads, like so: This process is pretty complicated! And it’s expensive. For Firefox to render at 60fps, we have about 16ms to process input events, JavaScript code, perform garbage collection, and render everything to the screen. We want to maximize the time available for input events and JavaScript, and minimize the time we spend crunching pixels. Otherwise… the browser appears to lag, skip, or pause. The Compositing step already happens off the main thread, but the other major steps do not. And while rasterization is not always expensive, it can be, and it is very much affected by resolution. Rasterizing on a 4K monitor requires computing roughly 10 times as many pixels  than, say, a 1024×768 screen. Off Main Thread Painting is our answer to rasterization costs. As the name suggests – we simply do it on another thread! It turned out to be surprisingly easy – with an asterisk. Normally, our display items render through an API we call Moz2D. Moz2D was already designed to support multiple backends – Skia, Cairo, Direct2D, et cetera. We added an additional “Capture” backend, where instead of immediately issuing commands, we can record them in a list. That list then gets replayed on a painting thread. Voilà! Rasterization is now asynchronous. The new diagram looks like this: Notice that the final rendering step now flows from the paint thread. That’s intentional – as soon as the main thread is done recording, we can return to the event loop and begin processing JavaScript and input events again. The paint thread now has the responsibility of sending new “painted” layer content to the compositor. What happens if painting takes multiple frames to complete? Say the paint thread is going to take 100ms to rasterize a very complex recording. Will the main thread keep piling up new frames and sending them to the paint thread? The answer is: no. Because Firefox double buffers, we currently cannot allow more than one frame of slack. If we begin rendering a new frame, we will wait for the previous frame to finish. Luckily since we only render on vertical sync (every 16ms on a 60hz display), this affords us a full 32ms (minus whatever time we spent preparing and recording the previous frame, of course) before we start delaying work on the main thread. To see why this is beneficial, imagine a series of frames before and after OMTP. If each frame exceeds the frame budget – even if rasterization was not the biggest component (like it is in the diagram below) – our composite will be delayed until the next vsync. In the diagram below, not only are we missing frames, but we’re spending a good deal of time doing nothing. Now, imagine the same content being rendered with OMTP. The main-thread is now recording commands and sending them to the paint thread. We can resume processing the next frame up until another rasterization needs to be queued. As long as neither thread exceeds its frame budget, we’ll always be able to composite on time. And if even if we blow the frame budget – at least we’ll get a few more frames in than the previous diagram. Data-Driven Decision When we started planning for future Graphics team work last year, we set out by instrumenting Firefox with Telemetry. We wanted to know how much painting was affecting frame time, and in addition, we wanted to know more about slow paints. When painting exceeded a certain threshold (set to 15ms), how was that time divided between different phases of the painting process? We had a gut feeling that rasterization was less of a cost than expected. Partly because it’s incremental (we rarely have to re-rasterize an entire page), and partly because we use Microsoft’s high-performance rasterization library, Direct2D. And indeed, our gut feelings were confirmed: for most “slow” paints, the costs were in the preparatory steps. Rasterization was sometimes a large chunk, but usually, it was somewhere between 10-20% of the entire paint cycle. Immediately, this data kicked off another project: Retained Display Lists, which the layout team will be talking about soon. Even though rasterization was usually fast, we had enough evidence that it did consume precious frame cycles, and that was motivation enough to embark on this project. Benchmarks A nice side effect of having instrumented Firefox is that we were pretty quickly able to see the effects of OMTP. The two graphs below are unfortunately a bit difficult to read or condense, but they are straight from our public Telemetry dashboard. On the left is data from Firefox 57, and on the right is data from Firefox 58. The horizontal axis is how expensive rasterization was as a percentage of the total frame time. The vertical axis is how often that particular weighting occurred. In Firefox 57, “cheap” rasterizations (those less than ~10% of the paint cycle) occur 51% of the time. In Firefox 58, they occur 80% of the time! That means in Firefox 58, rasterization will consume less of the frame budget on average. Similarly, in Firefox 57, rasterization is a significant slice – 50% of the paint cycle or more – 21% of the time. In Firefox 58, that scenario occurs only 4% of the time! To get a better feel for absolute effects, we also developed a microbenchmark called “rasterflood_svg”. It tries to simulate painting during a very heavy workload by spending 14ms of each frame spinning the CPU on JavaScript, and then forcing the browser to re-render a complex SVG pattern. In theory, OMTP should improve our framerate on a benchmark like this, because more time is available to render before the next frame begins. It closely matches the vsync diagram from earlier. And indeed, we do see benefits! With Direct2D, our microbenchmark improved FPS by 30%. And with Skia, our microbenchmark improved FPS by 25%. We expect Skia wins to be even greater in the future as we experiment with parallel painting. Difficulties Earlier we mentioned this was easy to implement. If that’s the case, why didn’t we just do it a long time ago? There are a few reasons, but in actuality it was a super long road to get here, and it was only made simple by years of precursor work. This project required Off Main Thread Compositing and significant work to simplify and reduce complexity in both Layers and Moz2D. Some of that work was not even motivated until Electrolysis took off. We even had an earlier OMTP project (spearheaded by Jerry Shih for FirefoxOS), but it found roadblocks in our IPC layer. We were only able to overcome those roadblocks with the knowledge learned from past efforts, combined with later refactorings. There were also some thread-safety complications, of course. Our 2D API is “copy on write”. You can issue many draw calls to a Moz2D surface, and even create copies of the surface, but usually no actual computations are performed until the contents of a surface will be read. So, a copy of a surface is just a pointer. When the original surface is about to be mutated, any outstanding copies are told to immediately duplicate the underlying pixels, so they reflect the image as when the “copy” was created. Why did this pose problems for OMTP? Well, it turns out we copy Moz2D surfaces a lot. Those copies can be sent from the main thread to the paint thread. If the main thread happens to mutate the original surface while the paint thread tries to read from a shallow copy, there will be a race. We definitely don’t want to deep-copy all of our temporary surfaces on the main thread, so instead, we added per-surface synchronization to Moz2D. Finally, another issue we ran into was the Direct2D global lock. Rather than completely audit or overhaul how Direct2D is used on both threads, we decided to enable Direct2D thread safety. When this is enabled, Direct2D will hold a global lock during certain critical sections. For example, this lock is held during surface destruction/allocation, when surfaces are “flushed” to the GPU, and when surfaces are copied. A good deal of work was us hitting these contention points for various reasons and addressing them, sometimes by moving more code off the main thread, and sometimes by fixing silly mistakes. Future Work What’s left to do? We have a few follow-up projects in mind. Now that we have asynchronous painting, it makes sense to explore parallel painting as well. We already support “tiled” rendering on Mac, and now we can explore both asynchronous tiling and painting tiles and layers in parallel. We also want to explore how well this works on Windows, both with Skia and with Direct2D. Our “slow rasterization” benchmarks suggest that parallel painting will be a huge win for Skia. There are also just some missing features in OMTP right now. For example, we do not support rasterizing “mask” layers on the paint thread. We would like to move some of this functionality out of the renderer into Advanced Layers, where masking can be done in our new, much-more-intelligent batching compositor. I’d like to thank Mason Chang, Ryan Hunt, Bas Schouten, Jerry Shih, Matt Woodrow, and our 2017 intern Dominic Farolino for contributing to these projects and getting them out the door! [Less]

Introduction At Mozilla, we're quickly climbing up our Data Science Hierarchy of Needs 1. I think the next big step for our data team is to make experimentation feel natural. There are a few components to this (e.g. training or culture) but improving the tooling is going to be …

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust ... [More] or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR. Updates from Rust Community News & Blog Posts Rust Playground can now output in WebAssembly. Building and deploying a Rust library on Android. Building and deploying a Rust library on iOS. Boiling the ocean, incrementally - How Stylo brought Rust and Servo to Firefox. Mercurial's oxidation plan: Using Rust in Mercurial. Diesel: Schema in depth. The rise of Rust in Dev/Ops. What's a reference in Rust? Replacing Elasticsearch with Rust and SQLite. Rust comes to RISC-V. Rust on ARM Cortex-M microcontrollers. Writing a Brainfuck interpreter in Rust (and WebAssembly). Learning Rust: Modules, crates, workspaces, std modules, and preludes. Rocket - A Rust game running on WebAssembly. Failure 0.1.1 released: Now with bail! and ensure!. Writing a turn-based strategy game in Rust: Progress report. The impl period newsletter #4. This week in Rust docs 84. [podcast] Rusty Spike Podcast - episode 10. Rust 1.22, RISC-V, impl newsletter #4, more WASM work, Fennec and Stylo, and Bobby Holley’s Stylo writeup. Crate of the Week This week is a bit sad for lack of a crate. Look, if you want a weekly crate, submit your suggestions and votes for next week! Call for Participation Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. Contribute to Rust's 2017 impl period. If you are a Rust project owner and are looking for contributors, please submit tasks here. Updates from Rust Core 146 pull requests were merged in the last week allow nested groups in imports add an i128_lowering flag in TargetOptions implement the special repr(C)-non-clike-enum layout rustc: filter out bogus extern crate warnings rustc: prepare to enable ThinLTO by default incr.comp.: make traits::VTable encodable and decodable incr.comp.: remove ability to produce incr. comp. hashes during metadata export incr.comp.: remove an unnecessary HIR access which enables hashing spans for type definitions incr.comp.: load cached diagnostics lazily and allow more things in the cache incr.comp.: some preparatory work for caching more query results make coercions to ! in unreachable code a hard error stabilize const-calling existing const-fns in std remove semicolon note use suggestions instead of notes ref mismatches (for better tooling) avoid type-live-for-region obligations on dummy nodes suggest using slice when encountering let _ = ""[..]; add case insensitive comparison, besides Levenstein for DYM MIR: split Operand::Consume into Copy and Move MIR: Fix value moved diagnose messages MIR: Fix CopyPropagation regression (2) MIR borrowck: finalize check_access_permissions() MIR-borrowck: immutable unique closure upvars can be mutated disable jemalloc on executables for ios targets stabilize spin_loop_hint add a specialization of read_exact for Cursor reject '2' as a binary digit in internals of b: number formatting remove T: Sized on ptr::is_null() stabilize some ascii_ctype methods add std::sync::mpsc::Receiver::recv_deadline() generic Associated Types Parsing & Name Resolution impl From for AtomicBool implement From for TryRecvError and RecvTimeoutError deprecate the Formatter::flags method introduce LinkedList::drain_filter cargo: add a workspace.default-members config that overrides implied --all rustdoc: fix search results overlap rustdoc: fix deduplication of items rustdoc: hide private trait type params and show hidden items with document-private fix rustdoc item summaries that are headers rustdoc: fix global search New Contributors Christian Duerr Irina-Gabriela Popa Julian Kulesh Kenjiro Nakayama Kyle Huey Nikolay Merinov Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: No RFCs were approved this week. Final Comment Period Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are: [disposition: merge] Fallible collection allocation 1.0. [disposition: merge] Implicit caller location (third try to the unwrap/expect line info problem). [disposition: merge] Unsized rvalues. [disposition: merge] eRFC: Cargo build system integration. [disposition: merge] Type privacy and private-in-public lints. New RFCs Closures capture disjoint fields. Bury Error::description(). String reflection. Add a machine-readable JSON-output mode for Rust's libtest. Upcoming Events Dec 9. Rust Bangalore "2-Day" Hackathon. Dec 11. Seattle Rust Meetup. Dec 13. Rust Amsterdam: Theme night on Procedural Macros & Custom Derive Dec 13. Rust Community Team Meeting at #rust-community on irc.mozilla.org. Dec 13. Rust Documentation Team Meeting at #rust-docs on irc.mozilla.org. Dec 13. OpenTechSchool Berlin - Rust Hack and Learn. Dec 14. Rust release triage. Dec 14. Rust DC - Mid-month Rustful: Falcon. Dec 14. Columbus Rust Society - Monthly Meeting. Dec 20. Rust Community Team Meeting at #rust-community on irc.mozilla.org. Dec 20. Rust Documentation Team Meeting at #rust-docs on irc.mozilla.org. Dec 21. Cambridge Rust Meetup #6. If you are running a Rust event please add it to the calendar to get it mentioned here. Email the Rust Community Team for access. Rust Jobs No jobs listed for this week. Tweet us at @ThisWeekInRust to get your job offers listed here! Quote of the Week No quote was selected for QotW. Submit your quotes for next week! This Week in Rust is edited by: nasa42 and llogiq. [Less]

Here’s what happened on the MozMEAO SRE team from November 14th - December 5th. Current work SUMO Work continues on the SUMO move to AWS. We’ve provisioned a small RDS MySQL instance in AWS for development and tried importing a production ... [More] snapshot. The import took 30 hours on a db.t2.small instance, so we experimented with temporarily scaling the RDS instance to a an db.m4.xlarge. The import is now expected to complete in 5 hours. We will investigate if incremental backup/restore is an option for the production transition. MDN MDN had several short downtime events in November, caused by heavy load due to scraping. Our K8s liveness and readiness probes often forced pods to restart when MySQL was slow to respond. Several readiness and liveness probe changes were issued by @escattone and @jwhitlock to help alleviate the issue: eliminate DB dependency from liveness & readiness endpoints in Kuma adjust liveness tests, avoid DB query in middleware increase threshold of failure for liveness/readiness probes The November 2017 Kuma report has additional details. We now have a few load balancer infrastructure tests for MDN, implemented in this pull request. MDN Interactive-examples Caching is now more granular due to setting different cache times for different assets. Bedrock Bedrock is transitioning to a local Sqlite DB and clock process in every container. This removes the dependency on RDS and makes running Bedrock cheaper. In preparation for this change, S3 buckets have been created for dev, stage and prod. Links Github project tracking SRE work How MozMEAO SRE’s work [Less]

Here’s what happened in November in Kuma, the engine of MDN Web Docs: Shipped the first 21 interactive examples Added browser versions, list-style-type, and even more Browser Compatibility Data Shipped a sticky table of contents and other ... [More] article improvements Improved MDN in AWS and Kubernetes Shipped tweaks and fixes by merging 260 pull requests, including 33 pull requests from 27 new contributors. We’re planning on more of the same for December. Done in November Shipped the First Interactive Examples We’ve launched the new interactive examples on 20+ pages. Try them out on the pages for the CSS property box-shadow and the JavaScript method Array.slice. We’re monitoring the page load impact of this limited rollout, and if the results are good, we have another 400 examples ready to go, thanks to Mark Boas and others. Mark also added a JavaScript Interactive Examples Contributing Guide, so that contributors can create even more. We want the examples to be as fast as possible. Schalk Neethling improved the page load speed of the by using preload URLs (PR 4537). Stephanie Hobson and Schalk dived into HTTP/2, and identified require.js as a potential issue for this protocol (Kuma PR 4521 and Interactive Examples PR 329). Josh Mize added appropriate caching headers for the examples and static assets (PR 326). For the next level of speed gains, we’ll need to speed up the MDN pages themselves. One possibility is to serve developer.mozilla.org from a CDN, which will require big changes to make pages more cacheable. One issue is waffle flags, which allow us to experiment with per-user changes, at the cost of making pages uncacheable. Schalk has made steady progress in eliminating inactive waffle flag experiments, and this work will continue into December. Continued Migration of Browser Compatibility Data The Browser Compatibility Data project was the most active MDN project in November. 36.6% of the MDN pages (2284 total) have been converted. Here are some highlights: Imported more CSS data, such as the huge list of allowed values for the list-style-type property (this list uses georgian). This property alone required 7 PRs, starting with PR 576. Daniel D. Beck submitted 32 CSS PRs that were merged in November, and is making good progress on converting CSS data. Added browser and version validation, a month-long effort in PR 439 from Florian Scholz and Jean-Yves Perrier. Added a runtime_flag for features that can be enabled at browser startup (PR 615 from Florian Scholz). Add the first compatibility data for Samsung Internet for Android (PR 657 from first-time contributor Peter O'Shaughnessy). Shipped the new compatibility table to beta users. Stephanie Hobson resurrected a design that had been through a few rounds of user testing (PR 4436), and has made further improvements such as augmenting colors with gradients (PR 4511). For more details and to give us feedback, see Beta Testing New Compatability Tables on Discourse. Sticky Table of Contents and Other Article Improvements We shipped some additional article improvements in November. The new table of contents is limited to the top-level headings, and “sticks” to the top of the window at desktop sizes, showing where you are in a document and allowing fast navigation (PR 4510 from Stephanie Hobson). The breadcrumbs (showing where you are in the page hierarchy) have moved to the sidebar, and now has schema.org metadata tags. Stephanie also refreshed the style of the sidebar links. Stephanie also updated the visual hierarchy of article headings. This is most noticeable on elements, which are now indented with black space. Improved MDN in AWS and Kubernetes We continued to have performance and uptime issues in AWS in November. We’re prioritizing fixing these issues, and we’re delaying some 2017 plans, such as improving KumaScript translations and upgrading Django, to next year. We lost GZip compression in the move to AWS. Ryan Johnson added it back in PR 4522. This reduced the average page download time by 71% (0.57s to 0.16s), and contributed to a 6% decrease in page load time (4.2 to 4.0s). Heavy load due to scraping caused 6 downtimes totaling 35 minutes. We worked to improve the performance of unpopular pages that get high traffic from scrapers, such as document list views (PR 4463 from John Whitlock) and the revisions dashboard (PR 4520 from Josh Mize). This made the system more resilient. Kubernetes was contributing to the downtimes, by restarting web servers when they started to undergo heavy load and were slow to respond. We’ve adjusted our “readiness” and “liveness” probes so that Kubernetes will be more patient and more gentle (Infra PR 665 from Ryan Johnson). These changes have made MDN more resilient and reliable, but more work will be needed in December. Stephanie Hobson fixed the development favicon appearing in production (PR 4530), as well as an issue with lazy-loading web fonts (PR 4533). Ryan Johnson continues work on our deployment process. Pushing certain branches will cause Jenkins to take specific deployment steps. Pushing master will run tests and publish a Docker image. Pushing stage-push will deploy that image to stage.mdn.moz.works. Pushing stage-integration-tests will run browser and HTTP tests against that deployment. We’ll make these steps more reliable, add production variants, and then link them together into automated deployment pipelines. Shipped Tweaks and Fixes There were 260 PRs merged in November: 89 mdn/browser-compat-data PRs 76 mozilla/kuma PRs 38 mdn/kumascript PRs 32 mdn/interactive-examples PRs 16 mozmeao/infra PRs 9 mdn/data PRs Many of these were from external contributors, including several first-time contributions. Here are some of the highlights: Update chrome_url_overrides for Opera (BCD PR 559), from first-time contributor Zbyněk Eiselt. Mark add and set methods of Set, Map and WeakMap objects as partially implemented on IE 11 (BCD PR 586), from first-time contributor Ivan Buryak. Add link to Edge bug report for (BCD PR 592), from first-time contributor Michael Hogg. Update status for CSS Scroll Snapping properties (BCD PR 609), from first-time contributor Masataka Yakura. Update IANA timezone name support in Chrome/Opera (BCD PR 611), from first-time contributor jungshik. Update browser identifier declaration instructions (BCD PR 625), Fix schema documentation for flag (BCD PR 627), and Add example for Status information (BCD PR 628), from first-time contributor Ra’Shaun Stovall. Update support data for parseInt treatment of leading zeros (BCD PR 633), from first-time contributor Claude Pache. Update textarea @autocomplete compat data (BCD PR 637 and PR 673), from first-time contributor Matt N. Add sampleRate option to new AudioContext() (BCD PR 651), from first-time contributor Jedipedia. Add support for page_action for FF for Android (BCD PR 667), from first-time contributor Elad. Safari has implemented upgrade-insecure-requests (BCD PR 670), from first-time contributor Justyn Temme. TypedArray.toString (BCD PR 677), from first-time contributor Lambdac0re. Update support for content-security-policy (BCD PR 683), from first-time contributor Jakob Jarosch. Add note about Origin header when using POST requests in Edge (BCD PR 684), from first-time contributor Viktor. Add the ability for users to hide GitHub link from their public profile (bug 1360294, Kuma PR 4346), from Maton Anthony. Add details about the changes in the .env (Kuma PR 4494), from first-time contributor Pavan Gudiwada. Docker setup guidance (Kuma PR 4501), from first-time contributor Pavan Gudiwada. Enable Telugu (te) as candidate locale (bug 984149, Kuma PR 4547), from John Whitlock. Add curl as an alternative to wget (bug 1387505, Kuma PR 4570), from first-time contributor Deep Bhattacharyya. Add Mozilla Foundation End-of-Year callout (bug 1420535, Kuma PR 4572), from Stephanie Hobson. Add support for Bulgarian. (KumaScript PR 374), from first-time contributor Красимир Беров. Mark Background Tasks as Proposed Recommendation (KumaScript PR 390), from first-time contributor Masataka Yakura. Close tag properly (KumaScript PR 398), from first-time contributor antonio-piha. Add French for event properties (KumaScript PR 408), from first-time contributor Matilin Torre. Add Dutch translation (KumaScript PR 412), from first-time contributor evelijn. Fix a mistake in array-reduce comment (Interactive Examples PR 358), from first-time contributor Gal Pasternak. Fix AudioContext & OfflineAudioContext inheritance (Data PR 152), from first-time contributor Jedipedia. Planned for December Mozilla gathers for the All-Hands event in Austin, TX in December, which gives us a chance to get together, celebrate the year’s accomplishments, and plan for 2018. Mozilla offices will shut down for the last full week of December. This doesn’t leave a lot of time for coding. We’ll continue working on the projects we worked on in November. We’ll convert more Browser Compatibility data. We’ll tweak the AWS infrastructure. We’ll eliminate and convert more waffle flags. We’ll watch the interactive examples and improved compatibility tables, and ship them when ready. We’ll also take a step back, and ask if we’re spending time and attention on the most important things. We’ll think about our processes, and how they could better support our priorities. But mostly, we’ll try not to mess things up, so that we can enjoy the holidays with friends and family, and come back refreshed for 2018. [Less]

Update for the week ending Friday, December 1, 2017. New Requests – Onboarding Notification A/B testing Metrics  Requests Past Week Past Month Past Year New 1 35 278 Responded 1 (100%) 33 (94%) 268 (96%) Responded within 48h 1 (100%) 27 ... [More] (77%) 237 (85%) Avg. Response Time < 24 hours 33 hours 23 hours Looking for last week’s report? Click Here [Less]