I Use This!
Very High Activity

News

Analyzed 1 day ago. based on code collected 2 days ago.
Posted over 5 years ago by Scott DeVaney
Pick of the Month: ContextSearch by Mike B Select text to quickly search the phrase from an array of engines. “Very intuitive and customizable. Well done!” Featured: Word Count by Trishul Simply highlight text, right click, and select Word Count ... [More] to easily do just that. “Beautifully simple and incredibly useful for those of us who write for a living.” If you’d like to nominate an extension for featuring, please send it to amo-featured [at] mozilla [dot] org for the board’s consideration. We welcome you to submit your own add-on! The post February’s featured extensions appeared first on Mozilla Add-ons Blog. [Less]
Posted over 5 years ago by Ludovic Hirlimann
10 years ago, today I started working for Mozillamessaging. I was using my own computer until fosdem 2009 during which Davida and I ended up a MediaMarkt in Brussels to buy my Mac (I needed a mac in order to be able to test Linux, Windows and ... [More] MacOS), so I could properly work as the Thunderbird QA lead. When Mozilla phased out Thunderbird, I asked to join the IT team - my sneaky plan was to manage email but server side. I ended up in the SRE team that got renamed MOC. I've been contributing since probably 1999 (reporting bugs because mozilla wasn't available on my platform of choice). I've changed projects numerous time, The suite -> Camino -> Thunderbird -> IT. I've had 5 bosses. and used bugzilla probably more than what's good for my sanity. [Less]
Posted over 5 years ago by mconley
Highlights Check out this awesome 2018 retrospective post by nchevobbe about all the nice things that made it to the Console panel last year. The initial UI for the new Event Listener Breakpoints feature has landed! (pref: ... [More] devtools.debugger.features.event-listeners-breakpoints) This should make debugging sites on the web easier in Firefox! We are replacing our existing localization formats with a new shiny one: Fluent. You can track our progress on arewefluentyet.com – To this date we already have 2.3k FTL Messages! Fluent incoming! The default private browsing window page has been given a facelift and a new search input! Just in case you wanted to search for some engagement rings. We’ve released an Anti-Tracking policy document – check out this blog post for more details. Friends of the Firefox team Introductions Welcome back Prathiksha! Resolved bugs (excluding employees) Fixed more than one bug Akash Srivastava Arjun Krishna Babu Florens Verschelde :fvsch Jorg K (GMT+1) Tim Nguyen :ntim Varun [:vdey] New contributors (🌟 = first patch) 3DIndian swapped out the column picker GIF for an SVG Akash Srivastava swapped out some old PNGs for SVGs, and also got rid of some unused CSS 🌟 akshitha shetty fixed a visual glitch in the flex box inspector 🌟 chengy12 made it easier to port aboutDialog.js strings to Fluent 🌟 danielleleb12 ensured that siteDataSettings.js was using strict mode correctly Garvit Khatri got rid of some unused CSS variables 🌟 nickcowles9575 ported the Safe Mode dialog to Fluent Varun [:vdey] simplified some of our Telemetry testing code, and fixed a case where we weren’t showing a default icon for WebExtensions Project Updates Add-ons / Web Extensions Migration of the storage API to a much more efficient IndexedDB backend will ride the trains with 66 (this was previously enabled on Nightly only) The first batch of changes to not run extensions in private browsing mode by default landed, this is still behind a preference. Applications Screenshots Ian is working on an export for Firefox 67 that will notify uploaders the server is going away. Blog post with more details on what’s going on with Screenshots. Browser Architecture Profile-per-install coming to Nightly 67 Really Soon Now. Hidden about:preferences panels now get lazily loaded, which speeds up page load Timothy Guan-tin Chien – Bug 1520350 – Lazily load about:preferences markups from hidden panes r=jaws gandalf made it so that Fluent blocks layout to avoid flashes of untranslated content Developer Tools Docs: Thanks to Irene, we now have nice and up-to-date MDN documentation for 2 of our user-facing Firefox 65 features: Tracking CSS Changes, and the Flexbox Inspector. We have also largely overhauled our contribution docs. This will make it easier for anyone to start getting into Firefox DevTools development. Technical debt: We want to be able to work faster on the codebase, remove more XUL, get rid of intermittent failures, etc. As a result, we’re setting our plan to remove the Shader Editor, Canvas Debugger and WebAudio Editor in motion: look out for an announcement on the mailing list this week. Then later in 67, there will be a removal notice in DevTools, and in 68, the panels will be removed (we’ll make it possible for interested people to get the code, talk to yulia if you want to know more). We are also migrating the CSS Rules panels to React and Redux. It’s one of our oldest piece of code and also one of our most important. Migrating it means more opportunities to reuse code from other parts of DevTools, a more approachable and predictable codebase, and faster feature development times. Console: In progress right now: a brand new multi-line console editor (bug, tweet)! Because sometimes the things you want to do takes multiple lines. Layout Tools: We’re hard at work designing what the next layout debugging tools will be. People love our flex sizing inspection tool, and we want to do more like this. Ideas so far: debugging z-index stacking issues, debugging unwanted scrollbar issues, debugging inline layouts, etc. Introducing a new “markup badge” in the inspector, to quickly find out which elements have scrollable overflows: This will hopefully help you identify important elements in the DOM. Fission All teams continue to make progress on Fission DOM team working on core functionality (process switching, BrowsingContext, WindowProxies, PWindowGlobal, JS IPDL, etc.) Major work ongoing on rewriting SessionStore from JS to C++ MattN is converting the FormAutoFillListeners code to the actors infrastructure mconley is working on last dependencies to let the privileged process ride the trains Other work: Shared UA style sheets, shared font lists Lint Myk is working on expanding the ESLint rule padded-blocks to the whole tree (bug). The ChromeUtils.import changes that Kris is working on, will eventually mean we can get rid of the manually maintained modules.json. However, currently that is still used, so we need to keep updating it for the time being when we change exports. NodeJS JS Debugger has started using Babel (for jsx)/Jest (elegant JS unit tests)/Flow (type-checking for front-end). Also hoping to start using webpack this week to build the debugger workers. Password Manager Prathiksha started last week on the team, joining the rest of the developers formerly on Web Payments Working on a short-term bug list (low-hanging fruit and test fixes) while we work with Lockbox to figure out the longer-term roadmap Performance dthayer has a PoC for a warm-up service that preloads DLLs during Windows start-up, reducing the time to first-paint for Firefox. Trade-offs are still being studied. felipe’s work to implement a subset of the Photon tab animations landed and bounced, getting close to sticking though Gijs’s work to lower frame rate on low-end machines has been queued for study. He also fixed a tp6 perf regression mconley has a patch up to enable the process priority manager on Nightly for Windows. Expect mail to dev-platform and firefox-dev about that. The patch to cause promiseDocumentFlushed to reject if the DOM has been modified in the callback is on autoland. https://perf-html.io/compare/ was deployed yesterday and provides a way to see 2 profiles at once to compare them. Policy Engine Added policies for min/max SSL version (1522182) Working on local file blocking (1450309) and extension whitelisting (1498745) Privacy/Security We’re planning to change how cookie prefs and permissions are picked up by live documents. We released a new version of the Multi-Account-Container extension, brought to you by Outreachy intern Shivangi Kakkar. We turned on the MitM error page by default in 66, alerting users that their connection is probably broken because of an application in the middle of their traffic. Search and Navigation Search switching built-in search engines to WebExtensions is on track for v67, current forecast is to merge it next week Quantum Bar Lots of bug fixes and code cleanups, list too long, but now we have quantumbar-nightly and quantumbar-release tracking bugs Missing features ported from the legacy address bar: bookmark tags, paste-and-go, URL canonization, speculative connections, autofill, clearing history Improved test coverage: existing address bar tests have been moved from browser/base/content to browser/components/urlbar, and are split into a browser/ and a legacy/ folders, until we are done converting them. Converted tests will run on both old and new implementation, through a test abstraction in UrlbarTestUtils.jsm [Less]
Posted over 5 years ago by Martin Balfanz
We just released Firefox 65 with a number of new developer features that make it even easier for you to create, inspect and debug the web. Among all the features and bug fixes that made it to DevTools in this new release, we want to highlight two in ... [More] particular: Our brand new Flexbox Inspector Smarter JavaScript inspection and debugging We hope you’ll love using these tools just as much as we and our community loved creating them. Understand CSS layout like never before The Firefox DevTools team is on a mission to help you master CSS layout. We want you to go from “trying things until they work” to really understanding how your browser lays out a page. Introducing the Flexbox Inspector Flexbox is a powerful way to organize and distribute elements on a page, in a flexible way. To achieve this, the layout engine of the browser does a lot of things under the hood. When everything works like a charm, you don’t have to worry about this. But when problems appear in your layout it may feel frustrating, and you may really need to understand why elements behave a certain way. That’s exactly what the Flexbox Inspector is focused on. Highlighting containers, lines, and items First and foremost, the Flexbox Inspector highlights the elements that make up your flexbox layout: the container, lines and items. Being able to see where these start and end — and how far apart they are — will go a long way to helping you understand what’s going on. Once toggled, the highlighter shows three main parts: A dotted outline that highlights the flex container itself Solid lines that show where the flex items are A background pattern that represents the free space between items One way to toggle the highlighter for a flexbox container is by clicking its “flex” badge in the inspector.  This is an easy way to find flex containers while you’re scanning elements in the DOM. Additionally, you can turn on the highlighter from the flex icon in the CSS rules panel, as well as from the toggle in the new Flexbox section of the layout sidebar. Understanding how flex items got their size The beauty of Flexbox is that you can leave the browser in charge of making the right layout decisions for you. How much should an element stretch, or should an element wrap to a new line? But when you give up control, how do you know what the browser is actually doing? The Flexbox Inspector comes with functionality to show how the browser distributed the sizing for a given item. The layout sidebar now contains a Flex Container section that lists all the flex items, in addition to providing information about the container itself. Clicking any of these flex items opens the Flex Item section that displays exactly how the browser calculated the item size. The diagram at the top of the flexbox section shows a quick overview of the steps the browser took to give the item its size. It shows your item’s base size (either its minimum content size or its flex-basis size), the amount of flexible space that was added (flex-grow) or removed (flex-shrink) from it, and any minimum or maximum defined sizes that restricted the item from becoming any shorter or longer. If you are reading this on Firefox 65, you can take this for a spin right now! Open the Inspector on this page, and select the div.masthead.row element. Look for the Flex Container panel in the sidebar, and click on the 2 items to see how their sizes are computed by the browser. After the bug fix, keep track of changes Let’s suppose you have fixed a flexbox bug thanks to the Flexbox Inspector. To do so, you’ve made a few edits to various CSS rules and elements. That’s when you’re usually faced with a problem we’ve all had: “What did I actually change to make it work?”. In Firefox 65, we’ve also introduced a new Changes panel to do just that. It keeps track of all the CSS changes you’ve made within the inspector, so you can keep working as you normally would. Once you’re happy, open the Changes tab and see everything you did. What’s next for layout tools? We’re really excited for you to try these two new features and let us know what you think. But there’s more in store. You’ve been telling us exactly what your biggest CSS challenges are, and we’ve been listening. We’re currently prototyping layout tools for debugging unwanted scrollbars, z-indexes that don’t work, and more tools like the Flexbox Inspector but for other types of layouts. Also, we’re going to make it even easier for you to extract your changes from the Changes panel. Smarter JavaScript inspection & debugging When developing JavaScript, the Console and Debugger are your windows into your code’s execution flow and state changes. Over the past releases we’ve focused on making debugging work better for modern toolchains. Firefox 65 continues this theme. Collapsing Framework Stack Traces If you’re working with frameworks and build tools, then you’re used to seeing really long error stack traces in the Console. The new smarter stack traces identify 3rd party code (such as frameworks) and collapse it by default. This significantly reduces the information displayed in the Console and lets you focus on your code. The Collapsing feature works in the Console stack traces for errors and logs, and in the Debugger call stacks. Reverse search your Console history If you are tired of smashing the arrow key to find that awesome one-liner you ran one hour ago in the console, then this is for you. Reverse search is a well known command-line feature that lets you quickly browse recent commands that match the entered string. To use it in the Console, press F9 on Windows/Linux or Ctrl+R on MacOS and start typing. You can then use Ctrl+R to move to the previous or Ctrl+S to the next result. Finally, hit return to confirm. Invoke getters to inspect the return value JavaScript getters are very useful for dynamic properties and heavily used in frameworks like vue.js for computed properties. But when you log an object with a getter to the Console, the reference to the method is logged, not its return value. The method does not get invoked automatically, as that could change your application’s state. Since you often actually want to see the value, you can now manually invoke getters on logged objects. Wherever objects can be inspected, in the Console or Debugger, you’ll see >> icons next to getters. Clicking these will execute the method and print the return value. Pause on XHR/Fetch Breakpoints Console logging is just one aspect of understanding application state. For complex issues, you need to pause state at precisely the right moment. Fetching data is usually one of those moments, and it is now made “pausable” with the new XHR/Fetch Breakpoint in the Debugger. Kudos to Firefox DevTools code contributor Anshul Malik for “casually” submitting the patch for this useful feature and for his ongoing contributions. What’s next for JavaScript debugging? You might have noticed that we’ve been heads down over recent releases to make the JavaScript debugging experience rock solid – for breakpoints, stepping, source maps, performance, etc. Raising the quality bar and continuing to polish and refine remains the focus for the entire team. There’s work in progress on much requested features like Column Breakpoints, Logpoints, Event and DOM Breakpoints. Building out the authoring experience in the Console, we are adding an multi-line editing mode (inspired by Firebug) and a more powerful autocomplete. Keep an eye out for those features in the latest release of Firefox Developer Edition. Thank you Countless contributors helped DevTools staff by filing bugs, writing patches and verifying them. Special thanks go to: Zameer Haque: Improved contrast for resource status in the Console. Heng Yeow: Added the Referrer-Policy to the resource Headers list in the Network panel (and fixed other bugs). Adam Holm: Updated the design for the Edit & Resend dialog in the Network panel. Ariel Burone: Swapped the Domain and File column in the Network panel. Also, thanks to Patrick Brosset, Nicolas Chevobbe and the whole DevTools team & friends for helping put together this article. Contribute As always, we would love to hear your feedback on how we can improve DevTools and the browser. File bug reports in Bugzilla Chat with us in the Firefox DevTools Slack Share ideas and questions in Mozilla’s Developer Tools Discourse  Tweet us at @FirefoxDevTools Download Firefox Developer Edition to get early access to upcoming tooling and platform. The post New in Firefox DevTools 65 appeared first on Mozilla Hacks - the Web developer blog. [Less]
Posted over 5 years ago by Martin Balfanz
We just released Firefox 65 with a number of new developer features that make it even easier for you to create, inspect and debug the web. Among all the features and bug fixes that made it to DevTools in this new release, we want to highlight two in ... [More] particular: Our brand new Flexbox Inspector Smarter JavaScript inspection and debugging We hope you’ll love using these tools just as much as we and our community loved creating them. Understand CSS layout like never before The Firefox DevTools team is on a mission to help you master CSS layout. We want you to go from “trying things until they work” to really understanding how your browser lays out a page. Introducing the Flexbox Inspector Flexbox is a powerful way to organize and distribute elements on a page, in a flexible way. To achieve this, the layout engine of the browser does a lot of things under the hood. When everything works like a charm, you don’t have to worry about this. But when problems appear in your layout it may feel frustrating, and you may really need to understand why elements behave a certain way. That’s exactly what the Flexbox Inspector is focused on. Highlighting containers, lines, and items First and foremost, the Flexbox Inspector highlights the elements that make up your flexbox layout: the container, lines and items. Being able to see where these start and end — and how far apart they are — will go a long way to helping you understand what’s going on. Once toggled, the highlighter shows three main parts: A dotted outline that highlights the flex container itself Solid lines that show where the flex items are A background pattern that represents the free space between items One way to toggle the highlighter for a flexbox container is by clicking its “flex” badge in the inspector.  This is an easy way to find flex containers while you’re scanning elements in the DOM. Additionally, you can turn on the highlighter from the flex icon in the CSS rules panel, as well as from the toggle in the new Flexbox section of the layout sidebar. Understanding how flex items got their size The beauty of Flexbox is that you can leave the browser in charge of making the right layout decisions for you. How much should an element stretch, or should an element wrap to a new line? But when you give up control, how do you know what the browser is actually doing? The Flexbox Inspector comes with functionality to show how the browser distributed the sizing for a given item. The layout sidebar now contains a Flex Container section that lists all the flex items, in addition to providing information about the container itself. Clicking any of these flex items opens the Flex Item section that displays exactly how the browser calculated the item size. The diagram at the top of the flexbox section shows a quick overview of the steps the browser took to give the item its size. It shows your item’s base size (either its minimum content size or its flex-basis size), the amount of flexible space that was added (flex-grow) or removed (flex-shrink) from it, and any minimum or maximum defined sizes that restricted the item from becoming any shorter or longer. If you are reading this on Firefox 65, you can take this for a spin right now! Open the Inspector on this page, and select the div.masthead.row element. Look for the Flex Container panel in the sidebar, and click on the 2 items to see how their sizes are computed by the browser. After the bug fix, keep track of changes Let’s suppose you have fixed a flexbox bug thanks to the Flexbox Inspector. To do so, you’ve made a few edits to various CSS rules and elements. That’s when you’re usually faced with a problem we’ve all had: “What did I actually change to make it work?”. In Firefox 65, we’ve also introduced a new Changes panel to do just that. It keeps track of all the CSS changes you’ve made within the inspector, so you can keep working as you normally would. Once you’re happy, open the Changes tab and see everything you did. What’s next for layout tools? We’re really excited for you to try these two new features and let us know what you think. But there’s more in store. You’ve been telling us exactly what your biggest CSS challenges are, and we’ve been listening. We’re currently prototyping layout tools for debugging unwanted scrollbars, z-indexes that don’t work, and more tools like the Flexbox Inspector but for other types of layouts. Also, we’re going to make it even easier for you to extract your changes from the Changes panel. Smarter JavaScript inspection & debugging When developing JavaScript, the Console and Debugger are your windows into your code’s execution flow and state changes. Over the past releases we’ve focused on making debugging work better for modern toolchains. Firefox 65 continues this theme. Collapsing Framework Stack Traces If you’re working with frameworks and build tools, then you’re used to seeing really long error stack traces in the Console. The new smarter stack traces identify 3rd party code (such as frameworks) and collapse it by default. This significantly reduces the information displayed in the Console and lets you focus on your code. The Collapsing feature works in the Console stack traces for errors and logs, and in the Debugger call stacks. Reverse search your Console history If you are tired of smashing the arrow key to find that awesome one-liner you ran one hour ago in the console, then this is for you. Reverse search is a well known command-line feature that lets you quickly browse recent commands that match the entered string. To use it in the Console, press F9 on Windows/Linux or Ctrl+R on MacOS and start typing. You can then use Ctrl+R to move to the previous or Ctrl+S to the next result. Finally, hit return to confirm. Invoke getters to inspect the return value JavaScript getters are very useful for dynamic properties and heavily used in frameworks like vue.js for computed properties. But when you log an object with a getter to the Console, the reference to the method is logged, not its return value. The method does not get invoked automatically, as that could change your application’s state. Since you often actually want to see the value, you can now manually invoke getters on logged objects. Wherever objects can be inspected, in the Console or Debugger, you’ll see >> icons next to getters. Clicking these will execute the method and print the return value. Pause on XHR/Fetch Breakpoints Console logging is just one aspect of understanding application state. For complex issues, you need to pause state at precisely the right moment. Fetching data is usually one of those moments, and it is now made “pausable” with the new XHR/Fetch Breakpoint in the Debugger. Kudos to Firefox DevTools code contributor Anshul Malik for “casually” submitting the patch for this useful feature and for his ongoing contributions. What’s next for JavaScript debugging? You might have noticed that we’ve been heads down over recent releases to make the JavaScript debugging experience rock solid – for breakpoints, stepping, source maps, performance, etc. Raising the quality bar and continuing to polish and refine remains the focus for the entire team. There’s work in progress on much requested features like Column Breakpoints, Logpoints, Event and DOM Breakpoints. Building out the authoring experience in the Console, we are adding an multi-line editing mode (inspired by Firebug) and a more powerful autocomplete. Keep an eye out for those features in the latest release of Firefox Developer Edition. Thank you Countless contributors helped DevTools staff by filing bugs, writing patches and verifying them. Special thanks go to: Zameer Haque: Improved contrast for resource status in the Console. Heng Yeow: Added the Referrer-Policy to the resource Headers list in the Network panel (and fixed other bugs). Adam Holm: Updated the design for the Edit & Resend dialog in the Network panel. Ariel Burone: Swapped the Domain and File column in the Network panel. Also, thanks to Patrick Brosset, Nicolas Chevobbe and the whole DevTools team & friends for helping put together this article. Contribute As always, we would love to hear your feedback on how we can improve DevTools and the browser. File bug reports in Bugzilla Chat with us in the Firefox DevTools Slack Share ideas and questions in Mozilla’s Developer Tools Discourse  Tweet us at @FirefoxDevTools Download Firefox Developer Edition to get early access to upcoming tooling and platform. The post New in Firefox DevTools 65 appeared first on Mozilla Hacks - the Web developer blog. [Less]
Posted over 5 years ago by Nical
Greetings! WebRender’s best and only newsletter is here. The number of blocker bugs is rapidly decreasing, thanks to the efforts of everyone involved (staff and volunteers alike). The project is in a good enough shape that some people are now moving ... [More] on to other projects and we are starting to experiment with webrender on new hardware. WebRender is now enabled by default in Nightly for some subset of AMD GPUs on Windows and we are looking into Intel integrated GPUs as well. As usual we start with small subsets with the goal of gradually expanding in order to avoid running into an overwhelming amount of platform/configuration specific bugs at once. Notable WebRender and Gecko changes Bobby improved the test infrastructure for picture caching. Jeff added restrictions to filter inputs. Jeff enabled WebRender for a subset of AMD GPUs on Windows. Matt fixed a filter clipping issue. Matt made a few improvements to blob image performance. Emilio fixed perspective scrolling. Lee worked around transform animation detection disabling sub-pixel AA on some sites. Lee fixed fixed the dwrote font descriptor handling so we don’t crash anymore on missing fonts. Lee, Jeff and Andrew fixed how we handle snapping with the will-change property and animated transforms. Glenn improved the accuracy of sub-pixel box shadows. Glenn fixed double inflation of text shadows. Glenn added GPU timers for scale operations. Glenn optimized drawing axis-aligned clip rectangles into clip masks. Glenn used down-scaling more often to avoid large blur radii. Glenn and Nical fixed uneven rendering of transformed shadows with fractional offsets. Nical rewrote the tile decomposition logic to support negative tile offsets and arbitrary tiling origins. Nical surveyed the available GPU debugging tools and documented the workarounds. Sotaro fixed a bug with the lifetime of animations. Sotaro skipped a test which is specific to how non-webrender backends work. Sotaro fixed another test that was specific to the non-webrender rendering logic. Sotaro fixed a bug in the iteration over image bridges when dispatching compositing notifications. Doug made APZ document-splitting-aware. Kvark fixed a perspective interpolation issue. Ongoing work The team keeps going through the remaining blockers (3 P2 bugs and 11 P3 bugs at the time of writing). Enabling WebRender in Firefox Nightly In about:config, set the pref “gfx.webrender.all” to true and restart the browser. Reporting bugs The best place to report bugs related to WebRender in Firefox is the Graphics :: WebRender component in bugzilla. Note that it is possible to log in with a github account. [Less]
Posted over 5 years ago by Mozilla
Today Denelle Dixon, Mozilla’s Chief Operating Officer, sent a letter to the European Commission surfacing concerns about the lack of publicly available data for political advertising on the Facebook platform. It has come to our attention that ... [More] Facebook has prevented third parties from conducting analysis of the ads on their platform. This impacts our ability to deliver transparency to EU citizens ahead of the EU elections. It also prevents any developer, researcher, or organization to develop tools, critical insights, and research designed to educate and empower users to understand and therefore resist targeted disinformation campaigns. Mozilla strongly believes that transparency cannot just be on the terms with which the world’s largest, most powerful tech companies are most comfortable. To have true transparency in this space, the Ad Archive API needs to be publicly available to everyone. This is all the more critical now that third party transparency tools have been blocked. We appreciate the work that Facebook has already done to counter the spread of disinformation, and we hope that it will fulfill its promises made under the Commission’s Code of Practice and deliver transparency to EU citizens ahead of the EU Parliamentary elections. Mozilla’s letter to European Commission on Facebook Transparency 31 01 19 The post Mozilla Raises Concerns Over Facebook’s Lack of Transparency appeared first on The Mozilla Blog. [Less]
Posted over 5 years ago by dylanwh
In this release: Support for OAuth2 w/jwt tokens, and a 10x performance boost to the bug search API. A welcome security enhancement from @psiinon as well: All responses get HSTS headers set. release tag the following changes have been pushed to ... [More] bugzilla.mozilla.org: [1511490] BMO’s oauth tokens should be use jwt [1519782] The OrangeFactor extension should link back to Intermittent Failure View using ‘&tree=all’ [1523004] Sort Phabricator revisions by numeric value instead of alphabetically [1523172] Advanced Search link on home page doesn’t always take me to Advanced Search [1523365]… View On WordPress [Less]
Posted over 5 years ago by Alex Gibson
It’s pretty commonplace today to write JavaScript using ES2015 (or ES6), and then to transpile that code to ES5 in a build step, using something like Babel. Transpiling enables us to write code using the latest ECMAScript syntax and features, but ... [More] then compiles it in a backward compatible way so that it works with older browsers. The downside to this is that transpiling can also lead to increased bundle sizes if you’re not careful, and for browsers that already support ES2015 features, you’re potentially shipping a lot of redundant code. Modern browsers need neither the transpiled code, nor the polyfills that can get bundled along with it. Before we get into the details of this post, I’ll start by emphasizing that depending on your project and its target audience, transpiling and bundling your JavaScript may be the exact right thing to do still. Browser segmentation and page load times are key metrics to measure. However, the with technologies like HTTP/2 and support for ES modules landing in all major browsers, we now have other options on the table. There is a new opportunity to build progressively enhanced websites using modern ES2015 features, but without as much of the bloat and complicated build steps we’ve become accustomed to. Cutting the mustard Feature detection has long been a useful technique to determine the code paths that run in our web pages. Techniques such as “cutting the mustard” have often been used to define a baseline of browser support for core functionality. Browsers that pass the test can run modern code, and older browsers are given a degraded experience. With ES modules, this kind of feature test can now evolve considerably. ES2015 introduced several new pieces of syntax, such as let, const, arrow functions, classes, and of course import and export for modules. Since this new syntax can’t be parsed by older browsers without throwing errors, web pages need a way to opt-in to use the new syntax where traditional feature detection falls short. Thankfully, web standards people are clever and have delivered such a mechanism! Modules to the rescue When the spec for loading ES modules was introduced, it added a new value for the type attribute to the tag, type="module". This acts as an identifier to browsers that the script is an ES module and can be loaded as such. It’s also important to note that modules use defer by default, so do not block the HTML parser like regular scripts. So how does this all tie together with progressive enhancement? Well, type="module" is a value that older browsers will not understand. When a browser encounters what it considers to be an invalid type, it won’t execute that script. Whilst it may still be downloaded, the script will not be parsed, and none of its import dependencies will be requested either. This allows us to safely use ES2015 features for modern browsers, and also improves page load performance for people on older browsers or operating systems, since they have less to download over the network. Older browsers can receive a nicely degraded experience of your choosing. Of course, if you still wanted to transpile and bundle code for older browsers, or provide some sort of baseline JS support then you can still do that too, using the nomodule attribute. This attribute signals to a browser that supports ES modules that the script can be ignored, meaning only older browsers will download and run it. If you’re building a progressively enhanced website, then depending on your approach this fallback may not even be needed. It really depends on your target audience and what you see as a suitable baseline experience. Performance As I mentioned at the beginning of this article, using unbundled ES modules in production today may not (yet) be a viable option for many large or complex websites. Using ES modules may result in shipping less code compared to transpiled code, but there are still trade-offs to shipping unbundled vs bundled scripts. Whilst browser vendors are continually working hard to improve module loading performance, you should still read about the current trade-offs and carefully measure the impact that modules may have before switching. For simpler websites or personal projects, using ES modules today may be just fine. It’s up to you to decide. Speeding up module loading If you do decide to use ES modules, you may also want to look into preloading, so that browsers can preparse modules and their dependencies as early as they can. Of course, minifying is also recommended as well. rel="modulepreload" href="./my-module.js"> Note: preloading is currently only supported in Chrome at the time of writing. A modern baseline, or a taste of the future? As we have seen, ES modules can provide a simple, modern baseline for building progressively enhanced websites that can still degrade gracefully on older browsers. Whilst this probably isn’t ready for large, complex websites just yet, it might just be fine for smaller sites and personal projects. To help tempt you, here’s a list of just some of the features that this technique unlocks access to: ES6 variables let, and const. Classes. Template literals. Static import and export in ES modules. Arrow functions. Promises. Async functions. fetch. If you would like to learn more about ES modules, Lin Clark wrote an excellent deep dive on the Mozilla Hacks blog. I highly suggest reading it. [Less]
Posted over 5 years ago by Owen Bennett
Lawmakers in the European Union are today focused on regulating online content, and compelling online services to make greater efforts to reduce the illegal and harmful activity on their services. As we’ve blogged previously, many of the present EU ... [More] initiatives – while well-intentioned – are falling far short of what is required in this space, and pose real threats to users rights online and the decentralised open internet. Ahead of the May 2019 elections, we’ll be taking a close look at the current state of content regulation in the EU, and advancing a vision for a more sustainable paradigm that adequately addresses lawmakers’ concerns within a rights- and ecosystem-protective framework. Concerns about illegal and harmful content online, and the role of online services in tackling it, is a policy issue that is driving the day in jurisdictions around the world. Whether it’s in India, the United States, or the European Union itself, lawmakers are grappling with what is ultimately a really hard problem – removing ‘bad’ content at scale without impacting ‘good’ content, and in ways that work for different types of internet services and that don’t radically change the open character of the internet. Regrettably, despite the fact that many great minds in government, academia, and civil society are working on this hard problem, online content regulation remains stuck in a paradigm that undermines users’ rights and the health of the internet ecosystem, without really improving users’ internet experience. More specifically, the policy approaches of today – epitomised in Europe by the proposed EU Terrorist Content regulation and the EU Copyright Reform directive – are characterised by three features that, together, fail to mitigate effectively the harms of bad content, while also failing to protect the good: Flawed metrics: The EU’s approach to content regulation today frames ‘success’ in terms of the speed and quantity of content removal. As we will see later in this series, this quantitative framing undermines proportionality and due process, and is unfitting for an internet defined by user-uploaded content. The lack of user safeguards: Under existing content control paradigms, online service providers are forced to play the role of judge and jury, and terms of service (ToS) effectively function as a law unto themselves. As regulation becomes ‘privatised’ in this way, users have little access to the redress and oversight that one is entitled to when fundamental rights are restricted. The one-size-fits-all approach: The internet is characterised by a rich diversity of service providers and use-cases. Yet at the same time, today’s online content control paradigm functions as if there is only one type of online service – namely, large, multinational social media companies. Forcing all online services to march to the compliance beat of a handful of powerful and well-resourced companies has the effect of undermining competition and internet openness. In that context, it is clear that the present model is not fit-for purpose, and there is an urgent need to rethink how we do online content regulation in Europe. At the same time, the fact that online content regulation at scale is a hard problem is not an excuse to do nothing. As we’ve highlighted before, illegal content is symptomatic of an unhealthy internet ecosystem, and addressing it is something that we care deeply about. To that end, we recently adopted an addendum to our Manifesto, in which we affirmed our commitment to an internet that promotes civil discourse, human dignity, and individual expression. The issue is also at the heart of our recently published Internet Health Report, through its dedicated section on digital inclusion. For these reasons, we’re focused on shaping a more progressive and sustainable discourse around online content regulation in the EU. In that endeavour there’s no time like the present: 2019 will see critical developments in EU policy initiatives around illegal and harmful content online (think terrorism, copyright, disinformation), and the new European Commission is expected to review the rules around intermediary liability in Europe – the cornerstone of online enforcement and compliance today. In the coming weeks, we’ll be using this blog to unpack the key considerations of online content regulation, and slowly build out a vision for what a better framework could look like. We hope you’ll join us on the journey.               The post Online content regulation in Europe: a paradigm for the future #1 appeared first on Open Policy & Advocacy. [Less]