fidzu : Mozilla

For the past year and a half I have been serving as one of two co-chairs of the U.S. Commerce Department Digital Economy Board of Advisors. The Board was appointed in March 2016 by then-Secretary of Commerce Penny Pritzer to serve a two year term. On Thursday I sent the letter below to Secretary Ross.

Dear Secretary Ross,
I am resigning from my position as a member and co-chair of the Commerce Department's Digital Economy Board of Advisors, effective immediately.
It is the responsibility of leaders to take action and lift up each and every American. Our leaders must unequivocally denounce bigotry, racism, sexism, hate, and violence.
The digital economy is fundamental to creating an economy that offers opportunity to all Americans. It has been an honor to serve as member and co-chair of this board and to work with the Commerce Department staff.
Sincerely,
Mitchell Baker
Executive Chairwoman
Mozilla

18 Aug 2017 7:12pm GMT

Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on in...

18 Aug 2017 6:00pm GMT

Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on in...

18 Aug 2017 6:00pm GMT

Hey, all cool kids have exciting Engineering Newsletters these days, so it's high time the JavaScript Binary AST got one! Summary JavaScript Binary AST is a joint project between Mozilla and Facebook to rethink how JavaScript source code is stored/transmitted/parsed. We expect that this project will help visibly speed up the loading of large codebases of JS applications and will have a large impact on the JS development community, including both web developers, Node developers, add-on developers and ourselves.

18 Aug 2017 11:46am GMT

It is hard to believe that we've gotten to the twentieth of these newsletters. That also means that we're very quickly approaching the finish line for this sprint. We only have a bit more than five more weeks to go before Firefox 57 merges to beta. It may be a good time to start to think more carefully about what we pay attention to in the remaining time, both in terms of the risk of patches landing, and the opportunity cost of what we decide to put off until 58 and the releases after.

We still have a large number of triaged bugs that are available for someone to pick up and work on. If you have some spare cycles, we really would appreciate if you consider picking one or two bugs from this list and working on them. They span many different areas of the codebase so finding something in your area of interest and expertise should hopefully be simple. Quantum Flow isn't the kind of project that requires fixing every single one of these bugs to be finished successfully, but at the same time big performance improvements often consist of many small parts, so the cumulative impact of a few additional fixes can make a big impact.

It is worth mentioning that lately while lurking on various tech news and blog sites where Nightly users comment, I have seen quite a few positive comments about Nightly performance from users. It's easy to get lost in the details of the work involved in getting rid of synchronous IPCs, synchronous layout/style flushes, unnecessary memory allocations, hashtable lookups, improving data locality, JavaScript JIT performance, making sure code gets inlined better, ship a new CSS engine, etc. etc. but it is reassuring to see people take notice.

Moving on to mention one point about Speedometer charts on AWFY which I have gotten a few questions about recently. We now have Speedometer benchmark numbers on Firefox Beta on the reference hardware reported in addition to inbound optimized and PGO builds. You may notice that the benchmark score numbers we are getting on Beta are around the same as Nightly (which swings around 83-84 these days). This doesn't mean that we haven't made any improvements on Nightly since the last Beta merge! We have some Nightly only telemetry code and some features that are only enabled on the Nightly channel, and those add a bit of overhead, which causes us to see a bit of an improvement after an uplift from mozilla-central to mozilla-beta without any code changes. This means that when the current code on Nightly gets merged to Beta 57, we should expect a bit of an improvement similarly.

And now let me take a moment to acknowledge the work of some of those who helped make Firefox faster last week. I hope I'm not dropping anyone's name mistakenly.

• Perry Jiang made _shouldCapture() run off of the idle queue and do nothing for about: pages. Perry also made it so that we don't unnecessarily load the autoscroll PNG when opening a new window.
• Kris Maglione fixed a recent regression causing extremely poor performance with extensions which have scripts creating large numbers of message listeners which never call their response callbacks. He also made code that registers a lot of lazy module and service getters use loops to make such code easier to optimize by SpiderMonkey JIT. He furthermore switched away from using FileUtils.getFile() which does main-thread I/O to check for the respective directory exists. Kris also made us not create the IndexedDB bindings in sandboxes since they're never used and avoided adding the caller location to the sandbox name if an explicit name if provided by the caller.
• Jan de Mooij added a megamorphic SetElement stub. He also optimized ToPropertyKey a bit.
• Nicolas B. Pierron optimized the LIRGenerator/CodeGenerator snapshot code.
• André Bargull removed some unnecessary allocations and rooting in the RegExp code. He also moved Array.prototype.sort entry point to self-hosted JS code in order to avoid frequent C++ to JS calls when sorting an array with a comparator argument present.
• Zibi Braniecki got rid of expensive per-option element styling that we used to have for select boxes in e10s mode.
• Adam Gashlin made us use a low priority timer for Places expiration.
• Henri Sivonen made the HTML parser atomize class attribute values for the class of single class values when parsing innerHTML strings. This speeds up parsing HTML strings used in innerHTML setters that have class="foo" attributes.
• Ting-Yu Chou ensured that we calculate the spill weight of a range's uses when we add to or remove from it, as opposed to the cache unfriendly iteration over the range's uses to calculate this information when needed.
• Mason Chang got rid of some graphics overhead that we had accidentally accumulated on the hidden window on macOS.
• Edouard Oger ensured that the sync-illustration SVG is not loaded until it's needed.
• Jonathan Watt avoided some hashtable lookups in undisplayed maps for elements without display:none or display:contents children.
• Blake Kaplan avoided some unneeded sync IPC for performing URI fix-up by creating a URI object explicitly in the content process.
• Jonathan Kew avoided some memory allocation churn in gfxFont::GetRoundOffsetsToPixels().

18 Aug 2017 5:26am GMT

We often see code benchmarks. Some browser X HTML renderer is faster than browser Y renderer. Some JavaScript engine outperforms the competition by two folds.

While these benchmarks give a kind of instant gratification for the product, they always make me dubious coming from anyone. If the target is to outperform another browser, then I sense that nothing useful has really been accomplished. Even as a marketing technique, I don't think it's working.

When/if publishing a benchmark, focus on three things:

• How this new code outperform the previous versions of the code? It's good to show that we care about our product and that we want to be faster where/when it matters.
• How does this improve the user experience on some specific sites? Improving speed in controled environment like benchmarks is nice, but improving speed on real cases Web site is even better. Did it make the JavaScript-controled scrolling faster and smoother?
• How did we get there? What are the steps which have been taken to improve the code performance? The coding tricks and techniques used to make it faster.

These will be benchmarks blog posts I like to read. So as a summary

Good benchmarks show 1. Outperform your own code 2. Real websites improvement demos 3. Give Technical explanations.

Otsukare!

18 Aug 2017 12:20am GMT

Intern Presentations 7 presenters Time: 1:00PM - 2:45PM (PDT) - each presenter will start every 15 minutes 3 SF, 1 TOR, 1 PDX, 2 Paris

17 Aug 2017 8:00pm GMT

Firefox had a baby and named it Focus! Firefox Focus is the new private browser for iOS and Android, made for those times when you just need something simple and … Read more

The post The Lightweight Browser: Firefox Focus Does Less, Which Is So Much More appeared first on The Firefox Frontier.

17 Aug 2017 4:31pm GMT

Together with help from leaders in Teaching Open Source(TOS), POSSE and others, I'm developing a series of learning modules intended to help Computer Science / Technical Students gain a holistic understanding of open source, with goals for build-in opportunities to 'learn by doing'. These modules are intended to enable students in their goals as they build Open Source Clubs(new website coming soon) on their campuses.

And I need your help!

I need your brain, what it knows about Open Source, what skills, knowledge, attitudes, visions you think are important and crucial. I also need your brain to ..um brainstorm(!) ideas for real world value in open source 'open educational' offerings.

There's a Github task for that!

Did I mention I need your Open Source Brain? I really do…

You'll find checklists for review at the bottom of each

• Module 1- Open is a noun, verb an attitude!
• Module 2 - Through the Looking Glass - Evaluating Open Source Projects
• Module 3 - Opening Your Project 101
• Module 4 - Stepping Into an Open Project (soft skills)
• Module 5 - Stepping Into an Open Project (technical skills)
• Module 6 - Prototyping your Future!
• Question! Creating Real World Value for Open Source 'Open Education' resources.

Share

16 Aug 2017 5:52pm GMT

We are happy to announce that Samsung Gear VR headset support is landing in Servo. The current implementation is WebVR 1.1 spec-compliant and supports both the remote and headset controllers available in the Samsung Gear VR 2017 model.

If you are eager to explore, you can download a project template compatible with Gear VR Android phones. Add your Oculus signature file, and run the project to launch the application on your mobile phone.

Alongside the Gear VR support, we worked on other Servo areas in order to provide A-Frame compatibility, WebGL extensions, optimized Android compilations and reduced Servo startup times.

A-Frame Compatibility

Servo now supports Mutation Observers that enables us to polyfill Custom Elements. Together with a solid WebVR architecture and better texture loading we can now run any A-Frame content across mobile (Google Daydream, Samsung Gear VR) and desktop (HTC Vive) platforms. All the pieces have fallen into place thanks to all the amazing work that the Servo team is doing.

WebGL Extensions

WebGL Extensions enable applications to get optimal performance by taking advantage of state-of-the-art GPU capabilities. This is even more important in VR because of the extra work required for stereo rendering. We designed the WebGL extension architecture and implemented some of the extensions used by A-Frame/Three.js such as float textures, instancing, compressed textures and VAOs.

Compiling Servo for Android

Recently, the Rust team changed the default Android compilations targets. They added an armv7-linux-androideabi target corresponding to the armeabi-v7a official ABI and changed the arm-linux-androideabi to correspond to the armeabi official ABI instead of armeabi-v7a.

This could cause important performance regressions on Servo because it was using the arm-linux-androideabi target by default. Using the new armv7 compilation target is easy for pure Rust based crates. It's not so trivial for cmake or makefile based dependencies because they infer the toolchain and compiler names based on the target name triple.

We adapted all the problematic dependencies. We took advantage of this work to add arm64 compilation support and provided a simple CLI API to select any Android compilation target in Servo.

Reduced startup times

C based libfontconfig library was causing long startup times in Servo for Android. We didn't find a way to fix the library itself so we opted to get rid of it and implement an alternative way to query Android system fonts. Unfortunately, Android doesn't provide an API to query system fonts until Android O so we were forced to parse the system configuration files and load fonts manually.

Gear VR support on Rust-WebVR Library

We started working on ovr-mobile-sys, the Rust bindings crate for the Oculus Mobile SDK API. We used rust-bindgen to automatically generate the bindings from the C headers but had to manually transpile some of the inline SDK header code since inline functions don't generate symbols and are not exported by rust-bindgen.

Then we added the SDK integration into the rust-webvr standalone library. The OculusVRService class offers the entry point to access Oculus SDK and handles life-cycle operations such as initialization, shutdown, and VR device discovery. The integration with the headset is implemented in OculusVRDisplay. Gear VR lacks positional tracking, but by using the neck model provided in the SDK, we expose a basic position vector simulating how the human head naturally rotates relative to the base of the neck.

In order to read Gear VR sensor inputs and submit frames to the headset, the Android activity must enter VR Mode by calling vrapi_EnterVrMode() function. Oculus Mobile SDK requires a precise life cycle management and handling some events that may interleave in complex ways. For a correct implementation the Android Activity must enter VR mode in a surfaceChanged() or onResume() event, whichever comes last. And it must leave VR mode in a surfaceDestroyed() or onPause() event, whichever comes first.

In a Glutin based Android NativeActivity, life cycle events are notified using Rust channels. This caused synchronization problems due to non-deterministic event handling in multithreading. We couldn't guarantee that the vrapi_LeaveVrMode() function was called before NativeActivity's EGLSurface was destroyed and the app went to background. Additionally, we needed to block the event notifier thread until Gear VR resources are freed, in a different renderer thread, to prevent collisions (e.g. Glutin dropping the EGLSurface at the same time that VR renderer thread was leaving VR mode). We contributed a deterministic event handling implementation to the Rust-android-glue.

Oculus mobile SDK allows to directly send a WebGL context texture to the headset. Despite that, we opted for a triple buffered swap chain recommended in the SDK to avoid potential flickering and performance problems when using the same texture every frame. As we did with the Daydream implementation, we render the VR-ready texture to the current ovrTextureSwapChain using a BlitFramebuffer-based solution, instead of rendering a quad, to avoid implementing the required OpenGL state-change safeguards or context switching.

Oculus Mobile SDK allowed us to directly attach the NativeActivity's surface to the Gear VR time warp renderer. We were able to run the pure Rust room-scale demo without writing a line of Java. It's nice that the SDK allows to achieve a java-free integration, but our luck changed when we integrated all this work into a full browser architecture.

Gear VR integration into Servo

Our Daydream integration worked inside Servo almost on a first try after it landed on the rust-webvr standalone library. This was not the case with the Gear VR integration…

First, we had to research and fix up to four specific GPU driver issues with the Mali-T880 GPU used in the Samsung Galaxy S7 phone:

• Float texture data was clamped to the maximum half-precision floating-point value (65504.0) when computed in the Servo's compositor shaders.
• Weird program linker error with a empty error message when two variants are set in the same shader function.
• Implement EGL Sync objects because glFlush is not enough to ensure that shared WebGL textures are correctly synced with the browser compositor.
• eglCreateContext failures when sharing two EGL Contexts with different CONTEXT_CLIENT_VERSION values in different threads.

As a result, we were able to see WebGL stereo rendering on the screen but entering VR mode crashed with a JNI assertion failure inside the Oculus VR SDK. This was caused because inside the browser context different threads are used for the rendering and VR device initialization/discovery. This requires the use of different Oculus ovrJava instances for each thread.

The assertion failure was gone but we couldn't see anything on the screen after calling vrapi_EnterVrMode(). The logcat error messages triggered by the Oculus SDK helped to find the cause of the problem. The Gear VR time warp implementation hijacks the explicitly passed Android window surface pointer. We could use the NativeActivity's window surface in the standalone room-scale demo. In a full browser architecture, however, there is a fight to take over ownership of the Android surface between time warp thread and the browser compositor. We discarded the idea of directly using the NativeActivity's window surface and decided to switch to a Java SurfaceView VR backend in order to make both the browser's compositor and Gear VR's time warp thread happy.

By this means, the VR mode life cycle fit nicely in the browser architecture. There was one final surprise though. The activity entered VR mode correctly, there were no errors in the logcat, time warp thread was showing correct render stats and the headset pose data was correctly fetched. Nevertheless, the VR scene with lens distortion was not yet visible in the Android view hierarchy. This led to a new instance of spending some hours of debugging to change a single line of code. The Android SurfaceView was being rendered correctly but it was composited below the NativeActivity's browser window because setZOrderOnTop() is not enabled by default on Android:

After this change everything worked flawlessly and it was time to enjoy running some WebVR experiences on the Gear VR ;)

Conclusion

It's been a lot of fun seeing Gear VR support land in Servo and being able to run A-Frame demos in it. We continue to work hard on squeezing WebGL and WebVR performance and expect to land some nice optimizations soon. We are also working on implementing unique WebVR features that no other browser has yet. More news soon ;) Stay tuned!

16 Aug 2017 5:41pm GMT

This is the sumo weekly call

16 Aug 2017 4:00pm GMT

Highlights

• Prathiksha added site permission settings for Location, Camera, Microphone and replaced the old permission dialog for Notifications in about:preferences.
  

  The new permission settings.

• jkt has improved the WebExtensions contextualIdentities APIs to the point where the Test Pilot Containers experiment can run as a WebExtension.
• Legacy Extensions, including classic and add-on SDK extensions, are now disabled by default in Nightly.
• Contributor UK92 made it possible to customize the position of the back/forward and reload/stop buttons.
• Felipe landed a patch that moves random timeouts to idle callbacks and got some solid performance improvements.
• Activity Stream rolling out in 56 to 10% of users on en-US builds, geolocated in USA and Canada. Up next is shipping to more users in more locales, and rolling out Pocket recommendations in Germany.
• The Page Action now has a Pocket item. Code for a screenshots item has landed in screenshots' github repo but needs screenshots to merge to m-c. Items can now be added/removed from the context menu. Finally, the Report Site Issue button has now also made its way into the page action menu for Nightly/DevEdition.
  

  Handy!

• The main toolbar now has 2 flexible spaces, one on either side of the url/search bar(s). The library button has also replaced the bookmarks menu button in the default toolbar set.

Friends of the Firefox team

• Resolved bugs (excluding employees): https://mzl.la/2x0m5n4
  • More than one bug fixed:
    • Alejandro Rodriguez Salamanca
    • Dan Banner
    • Hossain Al Ikram [:ikram] (QA Contact)
    • Masatoshi Kimura [:emk]
    • Michael Kohler [:mkohler]
    • Michael Smith [:mismith]
    • Richard Marti (:Paenglab)
    • Rob Wu [:robwu]
    • Tomislav Jovanovic :zombie
    • flyingrub
  • New contributors (🌟 = First Patch!)
    • ♥ Ami ♥ refactored `_handleMessage` in `UpdateTopLevelContentWindowIDHelper.jsm`.
      • Luciano I cleaned up unused variables in Sync code.

Project Updates

Add-ons

• Numerous bugs on out-of-process webextensions have been fixed.
• kmag has fixed a bunch of webextension performance issues.
• Sending a message to a tab no longer instantiates lazy tabs.
• The browsingData API can now clear local storage.
• ntim has added toolbar colors and per-window themes to the themes API.
• Little fixes to webRequest, optional permissions, downloads, experiments, hybrid extensions.
• rpl fixed several bugs with browser actions, page actions, and options on Android.

Activity Stream

• Landed pref'ed off in 56 Beta, with localization, snippets, performance telemetry, and Pocket recommendations.
• Up next
  • Adding "Recent Bookmarks" and "Recently Visited" to Highlights.
  • Adding custom sections via a Web Extension.
  • More customization for Top Sites: Pin/Dismiss, Show More/Less, Add/Edit Top Site.
  • Creating a site summary pipeline (high-res page icons -> Tippytop -> Screenshot + Favicon).
  • Optimizing metadata queries and Tippytop Icon DB improvements.

Firefox Core Engineering

• Installer
  • Profile cleanup option has landed in the stub installer for 57. Users who are running the stub installer and have an older version of Firefox installed will be presented with the option to clean up their profile.
• Updater
  • LZMA/SHA384 changes have landed as of 56 beta 3.
• Quantum & Photon Performance pile-on:
  • Felipe Gomes, Kirk Steuber, Adam Gashlin, Perry Jiang, Doug Thayer, Robert Strong closed 16 bugs and are currently on 11 more bugs.

Form Autofill

• Planning to enable address autofill (with sync) on beta in the next two weeks for en-US builds geolocated in the U.S.. Please file any issues you see.
• Address sync is enabled on Nightly. Enable it in about:preferences#sync
• Landed the following bugs:
  • Delay formautofill system add-on updates until the next restart
  • Exclude "united" string when applying "address-level1" regular expression
  • [Form Autofill] Handle filling in country field select element
  • 3.08% ts_paint_webext (windows7-32) regression on push 347ea0d06092d7fcd6c34e2c7ade389b0b71ae31 (Mon Aug 7 2017)
  • [Form Autofill] Enable the feature based on locale and geoip
  • Unhide addresses sync engine by default
  • Cache the matching result of select elements so we don't need to calculate it every time when previewing and filling
  • [Form Autofill] Edit dialog should not show horizontal and vertical scroll bars
  • [Form Autofill] Collect information on how many people enable credit card Autofill
  • [Form Autofill] Warn users on credit card fields that are not secure
  • The active area of the "Enable Profile Autofill" checkbox should expand to full width.
  • [Form Autofill] Autofill Options and Autofill phishing are not visible (w/o scrolling) in autofill dropdown when 6+ profiles
  • Flip "dom.forms.autocomplete.formautofill" according to the availability of Form Autofill feature
  • Make dom.forms.autocomplete.formautofill reflect actually supported autocomplete tokens
  • Preserve Form Autofill profiles during a Firefox Refresh/Reset

Photon

Structure

• We've migrated any additions you made to the old hamburger panel to the overflow panel, and removed some of the old code as well as the photon structure pref.
  • There's still a lot more to remove, see this bug if you have cycles to help.
• Lots of polish fixes: https://mzl.la/2x15jUZ - highlights:
  • WebExtension icons for sidebars now show up in the sidebar header
  • Panel styling has been tightened up, some icons swapped out
  • Keyboard navigation in panels was improved
  • Some overly narrow panels are now wider

Animation

• The new tab loading indicator got r+, we will work on landing it this week pending Talos runs
• Consolidated our blue accent colors to make sure that the same color is used throughout our animations
• The Save to Pocket animation was re-landed now that it runs in the page action area
• The Pin to Overflow animation was tweaked to not move the arrow as far low
• Minor bugs
  • Fixed a bug with entering/exiting Customize Mode causing the stop/reload animation to stop working
  • The Windows 10 Start Tile will now update with the new icon upon Firefox update. It previously only updated the icon for new installs.

Visuals

• We're mostly fixing bugs and polishing things right now.
• ntim updated the close icon style to match the Photon spec.
  

  The new tab close icons!

• Contributor Michael Kohler renamed the compact themes to just "Dark" and "Light" and removed all the MOZ_PHOTON_THEME ifdefs (phew!).
• Johann added a UI migration for compact dark/light themes to enable compact mode.
• Dão removed the tab title centering on Mac, making it consistent with our tab titles on the other platforms.

Preferences

• Continuing on visual refresh and update for 57. Please file bugs for visual styles in Preferences, Add-on Manager, other in-content pages, etc.

Privacy/Security

• Prathiksha made it that we hide the permission section in the identity popup on pages that display chrome UI (on about: pages).
  

  Perfection is achieved.

Sync / Firefox Accounts

• We're wrapping up iOS bidirectional sync work!
• Form Autofill Address sync is now enabled on Nightly. Enable it in about:preferences#sync

Test Pilot

• All Test Pilot experiments are off the Add-on SDK now!
• All Test Pilot add-ons are getting signed through a new signing pipeline (not AMO) to allow for non-WebExtensions in the future.
• Planning to roll out Screenshots to Release in the next couple of weeks.

Web Payments

• Landed:
  • Open and close a stub dialog when PaymentUIService's showPayment and abortPayment are called (respectively)
  • Moved to a remote frame for the dialog
• In Progress:
  • Add "abort" button in WebPayments dialog
  • Show origin and total roughly similar to the UX specs

16 Aug 2017 3:18pm GMT

TL;DR: I am going on holiday for a week and don't take any computer with me. When I'm back I will cut down on my travels, social media and conference participation and focus more on coaching others, writing and developing with a real production focus.

Larry shows how it is done

You won't hear much from me in the next week or so as I am taking a well-deserved vacation. I'm off to take my partner to the Cayman Islands to visit friends who have a house with a spare room as hotels started to feel like work for me. I'm also making the conscious decision to not take any computer with me as I will be tempted to do work whilst I am there. Which would be silly.

Having just been in a lot of meetings with other DevRel people and a great event about it I found a pattern: we all have no idea how to measure our success and feel oddly unsatisfied if not worried about this. And we are all worried about keeping up to do date in a daily changing market.

I'm doing OK on both of these, but I also suffer from the same worries. Furthermore, I am disturbed about the gap between what we talk about at events and workshops and what gets released in the market afterwards.

The huge gap between publication and application

We have all the information what not to do to create engaging, fast and reliable solutions. We have all the information how to even automate some of these to not disrupt fast development processes. And yet I feel a massive lack of longevity or maintainability in all the products I see and use. I even see a really disturbing re-emergence of "this only needs to work on browser $x and platform $y" thinking. As if the last decade hadn't happened. Business decisions dictate what goes into production, less so what we get excited about.

Even more worrying is security. We use a lot of third party code, give it full access to machines and fail to keep it up-to-date. We also happily use new and untested code in production even when the original developers state categorically that it shouldn't be used in that manner.

When it comes to following the tech news I see us tumbling in loops. Where in the past there was a monthly cadence of interesting things to come out, more readily available publication channels and a "stream of news" mentality makes it a full-time job just to keep up with what's happening.

Many thoughtpieces show up in several newsletters and get repurposed even if the original authors admitted in commentary that they were wrong. A lot is about being new and fast, not about being right.

There is also a weird premature productisation happening. When JavaScript, Browsers and the web weren't as ubiquitous as they are now, we showed and explained coding tricks and workarounds in blog posts. Now we find a solution, wrap it in a package or a library and release it for people to use. This is a natural progression in any software, but I miss the re-use and mulling around of the original thought. And I am also pretty sure that the usage numbers and stars on GitHub are pretty inflated.

My new (old) work modus

Instead of speaking at a high amount of conferences, I will be much pickier with where I go. My time is more limited now, and I want to use my talents to have a more direct impact. This is due to a few reasons:

• I want to be able to measure more directly what I do - it is a good feeling to be told that you were inspiring and great. But it fails to stay a good feeling when you don't directly see something coming out of it. That's why instead of going from event to event I will spend more time developing tools and working directly with people who build products.
• I joined a new team that is much more data driven - our job is to ensure people can build great apps and help them by fixing our platform and help them apply best practices instead of just hearing about them. This is exciting - I will be able to see just how applicable what we talk about really is and collect data of its impact. Just like any good trainer should ensure that the course attendees really learned what you talked about this is a full feedback loop for cool technologies like ServiceWorker and Push Nofifications.
• We just hired a truckload of talented people to coach - and I do want to see other people on stage than the usual suspects. It is great to see people grow with help you can give.
• I just had a cancer growth removed from my face - it was benign but it is kind of a wake-up call to take more care about myself and have my body looked after better on an ongoing basis
• I am moving to Berlin to exclusively live there with my partner and our dog - I've lived out of suitcases for years now and while this is great it is fun to have a proper home with people you care about to look after. I will very much miss London, but I am done with the politics there and I don't want to maintain two places any longer.
• I will spend more time coding - I am taking over some of the work on PWAbuilder and other helper tools and try them out directly with partners. Working in the open is great, but there is a huge difference between what Twitter wants and what people really need
• I will write more - both articles and blog posts. I will also have a massive stab at refreshing the Developer Evangelism Handbook
• I will work more with my employer and its partners - there is a huge group of gifted, but very busy developers out there that would love to use more state-of-the-art technology but have no time to try it out or to go to conferences.

Greetings from Berlin

What this means for events and meetups

Simple.

• I will attend less - instead I will connect conferences and meetups with other people who are not as in demand but great at what they do. I am also helping and mentoring people inside and outside the company to be invited instead of me. A lot of times a recommendation is all that is needed. And a helping hand in getting over the fear of "not being good enough".
• I will stay shorter - I want to still give keynotes and will consider more workshops. But I won't be booking conferences back-to-back and will not take part in a lot of the social activities. Unless my partner is also coming along. Even better when the dog is allowed, too.
• I am offering to help others - to review their work to get picked and help conference organisers to pick new, more diverse, talent.

I have a lot of friends who do events and I will keep supporting those I know have their full heart in them. I will also try to be supportive for others that need a boost for their new event. But I think it is a good time to help others step up. As my colleague Charles Morris just said at DevRelConf, "not all conferences need a Chris Heilmann". It is easy to get overly excited about the demand you create. But it is as important to not let it take over your life.

16 Aug 2017 2:59pm GMT

Last week I was in Seattle to attend a few meetings and I was lucky to attend DevRelSummit in the Galvanize space. I was invited to cover an "Ask me anything" slot about Developer Outreach in Microsoft and help out Charles Morris of the Edge team who gave a presentation a similar matter.

Q & A session with @Microsoft's @codepo8 about #devrel. #DevRelSummit #tech #microsoft pic.twitter.com/PFaW8Wi4Fl

- Angel Banks (@angelmbanks) August 11, 2017

It feels weird to have a conference that is pretty meta about the subject of Developer relations (and there is even a ConfConf for conference organisers), but I can wholeheartedly recommend DevRelSummit for people who already work in this field and those who want to.

The line-up and presentations were full of people who know their job and shared real information from the trenches instead of advertising products to help you. This is a very common worry when a new field in our job market gains traction. Anyone who runs events or outreach programs drowns in daily offers of "the turn-key solution to devrel success" or similar snake oil.

In short, the presentations were:

• Bear Douglas of Slack (formerly Twitter and Facebook) sharing wins and fails of developer outreach
• Charles Morris of Microsoft showing how he scaled from 3 people on the Edge team to a whole group, aligning engineering and outreach
• Kyle Paul showing how to grow a community in spaces that are not technical cool spots and how to measure DevFest success
• AJ Glasser of Unity explaining how to deal with and harvest feedback you get showing some traps to avoid
• Damon Hernandez of Samsung talking about building community around hackathons
• Linda Xie of Sourcegraph showing the product and growth cycle of a new software product
• Robert Nyman of Google showing how he got into DevRel and what can be done to stay safe and sound on the road
• Angel Banks and Beth Laing sharing the road to and the way to deliver an inclusive conference with their "We Rise" event as the example
• Jessica Tremblay and Sam Richard showing how IBM scaled their developer community

In between the presentations there were breakout discussions, lightning talks and general space and time to network and share information.

As expected, the huge topics of the event were increasing diversity, running events smoothly, scaling developer outreach and measuring devrel success. Also, as expected, there were dozens of ways and ideas how to do these things with consensus and agreeable discourse.

All in all, DevRelSummit was a very well executed event and a superb networking opportunity without any commercial overhead. There was a significant lack of grandstanding and it was exciting to have a clear and open information exchange amongst people who should be in competition but know that when it comes to building communities, this is not helpful. There is a finite amount of people we want to reach doing Developer Relations. There is no point in trying to subdivide this group even further.

Cheers to another successful @DevRelSummit, Sandra & Barry! ?@SandraPersing @bteiger pic.twitter.com/aPVfpvRe9w

- Tia Over (@tiaover) August 12, 2017

I want to thank everyone involved about the flawless execution and the willingness to share. Having a invite-only slack group with pre-set channels for each talk and session was incredibly helpful and means the conversations are going on right now.

DevRelSummit showed that when you get a dedicated group of people together who know their jobs and are willing to share that you can get an event to be highly educational without any of the drama that plights other events. We have a lot of problems to solve and many of them are very human issues. A common consensus of the event was that we have to deal with humans and relate to them. Numbers and products are good and useful, but not burning out or burning bridges even with the best of intentions are even more important.

16 Aug 2017 9:47am GMT

Intern Presentations 6 presenters Time: 1:00PM - 2:30PM (PDT) - each presenter will start every 15 minutes 5 MTV, 1 Berlin

15 Aug 2017 8:00pm GMT

The general release of Firefox 55 brought a number of cool new features to the Gecko platform, one of which is the WebVR API v1.1. This allows developers to create immersive VR experiences inside web apps, compatible with popular hardware such as HTC VIVE, Oculus Rift, and Google Daydream. This article looks at the resources we've made available to facilitate getting into WebVR development.

Support notes

Version 1.1 of the WebVR API is very new, with varying support available across modern browsers:

• Firefox 55 sees full support on Windows, and more experimental support available for Mac in the Beta/Nightly release channels only, until testing and final work is completed. Supported VR hardware includes HTC VIVE, Oculus Rift, and Google Daydream.
• Chrome support is still experimental - you can currently only see support out in the wild on Chrome for Android with Google Daydream.
• Edge fully supports WebVR 1.1, through the Windows Mixed Reality headset.
• Support is also available in Samsung Internet, via their GearVR hardware.

Note that the 1.0 version of the API can be considered obsolete, and has been (or will be) removed from all major browsers.

Controlling WebVR apps using the full features of VR controllers relies on the Gamepad Extensions API. This adds features to the Gamepad API that provide access to controller features like haptic actuators (e.g. vibration hardware) and position/orientation data (i.e., pose). This currently has even more limited support than the WebVR API; Firefox 55+ has it available in Beta/Nightly channels.

In other browsers, you'll have to make do for now with basic Gamepad API functionality, like reporting button presses.

vr.mozilla.org

vr.mozilla.org - Mozilla's new landing pad for WebVR - features demos, utilities, news and updates, and all the other information you'll need to get up and running with WebVR.

MDN documentation

MDN has full documentation available for both the APIs mentioned above. See:

• WebVR API reference
• Gamepad API reference, which includes the Gamepad Extensions API

In addition, we've written some useful guides to get you familiar with the basics of using these APIs:

• WebVR concepts
• Using the WebVR API
• Using VR controllers with WebVR

A-Frame and other libraries

WebVR experiences can be fairly complex to develop. The API itself is easy to use, but you need to use WebGL to create the 3D scenes you want to feature in your apps, and this can prove difficult to those not well-versed in low-level graphics programming. However, there are a number of libraries to hand that can help with this.

The hero of the WebVR world is Mozilla's A-Frame library, which allows you to create nice looking 3D scenes using custom HTML elements, handling all the WebGL for you behind the scenes. A-Frame apps are also WebVR-compatible by default. It is perfect for putting together apps and experiences quickly.

• A-Frame documentation
• A-Frame demos
• Salva's Tools for VR development article series

There are a number of other well-written 3D libraries available too, which abstract away the difficulty of working with raw WebGL. Good examples include:

• Three.js
• BabylonJS
• PlayCanvas

These don't include VR capabilities out of the box, but it is not too difficult to write your own WebVR rendering code around them.

If you are worried about supporting older browsers that only include WebVR 1.0 (or no VR) as well as newer browsers with 1.1, you'll be pleased to know that there is a WebVR polyfill available.

Demos and examples

• vr.mozilla.org - the main Mozilla landing pad for WebVR, with demos, utilities, and other information.
• webvr-tests - very simple examples to accompany the MDN WebVR documentation.
• Carmel starter kit - nice simple, well-commented examples that go along with Carmel, Facebook's WebVR browser.
• WebVR.info samples - slightly more in-depth examples plus source code
• WebVR.rocks Firefox demos - showcase examples
• A-Frame homepage - examples showing A-Frame usage

See also

• WebGL reference
• The <canvas> element

15 Aug 2017 1:30pm GMT