18 Aug 2017

feedPlanet Mozilla

Mitchell Baker: Resignation as co-chair of the Digital Economy Board of Advisors

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

Air Mozilla: Webdev Beer and Tell: August 2017, 18 Aug 2017

Webdev Beer and Tell: August 2017 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

Air Mozilla: Webdev Beer and Tell: August 2017, 18 Aug 2017

Webdev Beer and Tell: August 2017 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

David Teller: JavaScript Binary AST Engineering Newsletter #1

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

Ehsan Akhgari: Quantum Flow Engineering Newsletter #20

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.

18 Aug 2017 5:26am GMT

Karl Dubost: About Publishing Code Benchmarks

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:

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

17 Aug 2017

feedPlanet Mozilla

Air Mozilla: Intern Presentations: Round 5: Thursday, August 17th

Intern Presentations: Round 5: Thursday, August 17th 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

The Firefox Frontier: The Lightweight Browser: Firefox Focus Does Less, Which Is So Much More

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

16 Aug 2017

feedPlanet Mozilla

Emma Irwin: I Need Your Open Source Brain

Photo credit: Internet Archive Book Images via Visual Hunt / No known copyright restrictions

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

FacebookTwitterGoogle+Share

16 Aug 2017 5:52pm GMT

Mozilla VR Blog: Samsung Gear VR support lands in Servo

Samsung Gear VR support lands in Servo

Samsung Gear VR support lands in Servo

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

Samsung Gear VR support lands in Servo

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

Samsung Gear VR support lands in Servo

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:

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

Air Mozilla: Weekly SUMO Community Meeting August 16, 2017

Weekly SUMO Community Meeting August 16, 2017 This is the sumo weekly call

16 Aug 2017 4:00pm GMT

Firefox Nightly: These Weeks in Firefox: Issue 22

Highlights

Friends of the Firefox team

Project Updates

Add-ons

Activity Stream

Firefox Core Engineering

Form Autofill

Photon

Structure
Animation
Visuals
Preferences

Privacy/Security

Sync / Firefox Accounts

Test Pilot

Web Payments

16 Aug 2017 3:18pm GMT

Christian Heilmann: Taking a break – and so should you

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.

Sleeping dogLarry 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:

Anke, Larry and ChrisGreetings from Berlin

What this means for events and meetups

Simple.

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

Christian Heilmann: DevRelSummit was well worth it

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:

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.

Slack Channel of the event

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

15 Aug 2017

feedPlanet Mozilla

Air Mozilla: Intern Presentations: Round 4: Tuesday, August 15th

Intern Presentations: Round 4: Tuesday, August 15th 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

Hacks.Mozilla.Org: Essential WebVR resources

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:

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:

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

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.

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:

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

See also

15 Aug 2017 1:30pm GMT