mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

The Mozilla Blog: New Sharing Features in Firefox

Mozilla planet - do, 02/07/2015 - 22:58

Whichever social network you choose, it’s undeniable that being social is a key part of why you enjoy the Web. Firefox is built to put you in control, including making it easier to share anything you like on the Web’s most popular social networks. Today, we’re announcing that Firefox Share has been integrated into Firefox Hello. We introduced Firefox Share to offer a simple way of sharing Web content across popular services such as Facebook, Twitter, Tumblr, LinkedIn and Google+ and other social and email services  (full list here) to help you share anything on the Web with any or all of your friends.

Firefox Hello link sharing

Firefox Hello, which we’ve been developing in beta with our partner, Telefonica, is the only in-browser video chat tool that doesn’t require an account or extra software downloads. We recently added screen sharing to Firefox Hello to make it easier to share anything you’re looking at in your video call. Now you can also invite friends to a Firefox Hello video call by sharing a link via the social network or email account of your choice, all without leaving your browser tab. That includes a newly added Yahoo Mail integration in Firefox Share that lets Yahoo Mail users share Hello conversation links or other Web content directly from Firefox Share.

For more information:
Release Notes for Firefox for Windows, Mac, Linux
Release Notes for Android
Download Firefox

Categorieën: Mozilla-nl planet

New Sharing Features in Firefox

Mozilla Blog - do, 02/07/2015 - 22:58

Whichever social network you choose, it’s undeniable that being social is a key part of why you enjoy the Web. Firefox is built to put you in control, including making it easier to share anything you like on the Web’s most popular social networks. Today, we’re announcing that Firefox Share has been integrated into Firefox Hello. We introduced Firefox Share to offer a simple way of sharing Web content across popular services such as Facebook, Twitter, Tumblr, LinkedIn and Google+ and other social and email services  (full list here) to help you share anything on the Web with any or all of your friends.

Firefox Hello link sharing

Firefox Hello, which we’ve been developing in beta with our partner, Telefonica, is the only in-browser video chat tool that doesn’t require an account or extra software downloads. We recently added screen sharing to Firefox Hello to make it easier to share anything you’re looking at in your video call. Now you can also invite friends to a Firefox Hello video call by sharing a link via the social network or email account of your choice, all without leaving your browser tab. That includes a newly added Yahoo Mail integration in Firefox Share that lets Yahoo Mail users share Hello conversation links or other Web content directly from Firefox Share.

For more information:
Release Notes for Firefox for Windows, Mac, Linux
Release Notes for Android
Download Firefox

Categorieën: Mozilla-nl planet

Rust Never Sleeps: How Mozilla Could Become Cool Again - ReadWrite

Nieuws verzameld via Google - do, 02/07/2015 - 21:04

ReadWrite

Rust Never Sleeps: How Mozilla Could Become Cool Again
ReadWrite
Once it offered a serious competitive threat to Microsoft's Internet Explorer. Today, Mozilla's Firefox squeaks into third place with just 12% market share of desktop browsers, according to NetMarketShare, and is worse than a rounding error among ...

Categorieën: Mozilla-nl planet

Air Mozilla: German speaking community bi-weekly meeting

Mozilla planet - do, 02/07/2015 - 21:00

German speaking community bi-weekly meeting https://wiki.mozilla.org/De/Meetings

Categorieën: Mozilla-nl planet

Mozilla Games Technology Roadmap

Mozilla Futurereleases - do, 02/07/2015 - 20:30

In furthering the advantages and appeal of the Web as a platform for games and game technologies, Mozilla is publishing its games-focused roadmap. In short, it’s all about high-performance, plugin-free games on the Web. We have made incredible progress over the last few years; to continue this trend, Mozilla has been working with game developers and tool makers to identify additional enhancements that will further empower the community. The following roadmap outlines both the feedback we received and the solutions we are currently pursuing in response to this feedback. This roadmap may be subject to change.

With the unveiling of WebAssembly, browsers have taken another common step towards native levels of performance on the Web. This roadmap outlines the wider view of additional Web platform functionality needed to allow game developers to provide the best possible experiences. Games are often a great catalyst for driving technology forward due to their demanding nature. To maximize the benefit to the Web, care has been taken to ensure that solutions will benefit the widest possible range of applications.

There are two levels to this document. The first is the Roadmap section which contains areas that are currently in development and we have a reasonable level of confidence we can address in the next year. The second is the Under Consideration section which contains topics that are under active investigation.

Roadmap

  • Allow developers to better exploit hardware parallelism.
    • Developers are struggling to get multi-threaded games running efficiently on the Web:
      • Standardize, implement and ship SharedArrayBuffer [1,2].
      • Add pthreads support to Emscripten [1,2].
      • Expose performance-sensitive Web APIs to Web Workers: WebGL, WebSockets, IndexedDB, WebAudio, WebRTC, WebVR.
      • Share compiled code (asm.js and WebAssembly) between workers [1].
    • Developers want to take advantage of SIMD hardware to optimize their code:
      • Standardize, implement and ship SIMD.js [1,2].
      • Include SIMD in WebAssembly [1].
      • Add SIMD support to Emscripten [1].
  • Improve cold load time of large compiled codebases.
    • Developers want to see reduced download, compilation and startup time for multi-million line compiled codebases.
      • WebAssembly will provide significant download size reductions (even before native support, through the polyfill) [1].
      • Natively decoding WebAssembly will be significantly faster than parsing JavaScript/asm.js [1].
      • Add a fast WebAssembly/asm.js compiler that allows an app to start quickly while a fully-optimizing compilation proceeds in a background thread [1].
      • Off-main-thread, streaming parsing/compilation [1].
    • Developers want to avoid depending on HTTP Content-Encoding:gzip for generic compression.
      • Add Emscripten support to perform decompression in asm.js / WebAssembly while downloading (allowing more aggressive algorithms than gzip).
  • Improve browser storage capabilities.
    • Developers seeking to avoid the permission prompt associated with persistent storage hit limitations of temporary storage as currently implemented in browsers.
      • Improve temporary quota limits to take into account factors like frecency.
      • Provide more information on quota usage and allowance [1].
      • Propose, standardize and implement finer-granularity units of evictable storage [1].
      • Allow cross-origin storage usage [1].
    • Developers that need persistent storage guarantees hit limitations of persistent storage as currently implemented in browsers.
      • Standardize persistent storage so that other browsers implement [1].
      • Reduce UI friction associated with the persistent permission prompt [1].
      • Improve storage management/eviction UI for browser users.
  • Improve browser graphics capabilities.
    • Ship WebGL2 [1].
    • Standardize and implement streaming WebGL canvas via WebRTC [1,2].
    • Run WebGL on discrete hardware for systems with integrated+discrete (e.g. nVidia Optimus).
  • Allow developers to better avoid 32-bit browser Out-of-Memory conditions.
    • Ship 64-bit Firefox on 64-bit Windows.
    • Avoid Emscripten in-memory Virtual File System for asset storage by leveraging pthreads and FileReaderSync to provide synchronous file I/O in workers.
  • Continue investment in performance across the platform.
    • Significantly optimize WebAudio performance [1].
    • Reduce WebGL shader compile times [1,2].
    • Reduce latency and jitter in the browser’s rendering pipeline [1,2,3,4].
    • Continue investments in the performance of JS, DOM, WebGL, WebRTC, codec, layout, rendering, compositing, animation, etc.
  • Continue investment in Emscripten.
    • Add support for pthreads, SIMD, and WebAssembly, as mentioned above.
    • Further improve compilation speed.
  • Continue investment in Firefox developer tooling to better support game developers.
    • Improve Web Worker support [1].
    • Allow developers to break on various asm.js/WebAssembly error conditions [1].

Under Consideration

  • Developers are having trouble identifying how many Web Workers they should create to distribute their workload. Benchmarking methods often prove unreliable.
  • Developers are hitting the 20-per-origin limit on web workers in Firefox and are requesting a much higher limit.
  • Leverage multi-process browser architecture to guarantee a fresh address space for games with large contiguous heaps allocated early in process startup.
  • Investigate Out-of-Memory error reporting mechanism to send safe/sanitized triage information back to Web app developers.
  • Collaborate on new standards to improve IME capabilities [1,2].
  • Add hardware cursor API [1].
  • Improve Gamepad API [1].
  • Add Pointer Clipping extension to Pointer Lock API [1].
  • Add Emscripten tooling for memory use/leak debugging.
  • Standardize (as part of WebAssembly or more generally) a more scalable form of source maps suitable for large compiled codes.
Categorieën: Mozilla-nl planet

Mozilla Addons Blog: T-Shirt Form Data Exposure

Mozilla planet - do, 02/07/2015 - 20:17

On Monday, June 15, 2015 Mozilla announced on the Add-ons blog a free special edition t-shirt for eligible AMO developers. Eligible developers were requested to sign up via Google Form and asked to input their full name, full address, telephone number and T-shirt size.

This document was mistakenly configured to allow potential public access for less than 24 hours, exposing the response data for 70 developers. As soon as the incident was discovered, we immediately changed the permission level to private access. Other than the developer who discovered and reported this incident, we are not aware of anyone without authorization accessing the spreadsheet.

We have notified the affected individuals. We regret any inconvenience or concern this incident may have caused our AMO developer community.

Categorieën: Mozilla-nl planet

Air Mozilla: Web QA Weekly Meeting

Mozilla planet - do, 02/07/2015 - 18:00

Web QA Weekly Meeting This is our weekly gathering of Mozilla'a Web QA team filled with discussion on our current and future projects, ideas, demos, and fun facts.

Categorieën: Mozilla-nl planet

Roberto A. Vitillo: Telemetry metrics roll-ups

Mozilla planet - do, 02/07/2015 - 17:29

Our Telemetry aggregation system has been serving us well for quite some time. As Telemetry evolved though, maintaining the codebase and adding new features such as keyed histograms has proven to be challenging. With the introduction of unified FHR/Telemetry, we decided to rewrite the aggregation pipeline with an updated set of requirements in mind.

Metrics

A ping is the data payload that clients submit to our server. The payload contains, among other things, over thousand metrics of the following types:

  • numerical, like e.g. startup time
  • categorical, like e.g. operating system name
  • distributional, like e.g. garbage collection timings

Distributions are implemented with histograms that come in different shapes and sizes. For example, a keyed histogram represent a collection of labelled histograms. It’s not rare for keyed histograms to have thousands of possible labels. For instance, MISBEHAVING_ADDONS_JANK_LEVEL, which measures the longest blocking operation performed by an add-on, has potentially a label for each extensions.

The main objective of the aggregator is to create time or build-id based aggregates by a set of dimensions:

  • channel, e.g. nightly
  • build-id or submission date
  • metric name, e.g. GC_MS
  • label, for keyed histograms
  • application name, e.g. Fennec
  • application version, e.g. 41
  • CPU architecture, e.g. x86_64
  • operating system, e.g. Windows
  • operating system version, e.g. 6.1
  • e10s enabled
  • process type, e.g. content or parent

As scalar and categorical metrics are converted to histograms during the aggregation, ultimately we display only distributions in our dashboard.

Raw Storage

We receive millions of pings each day over all our channels. A raw uncompressed ping has a size of over 100KB. Pings are sent to our edge servers and end up being stored in an immutable chunk of up to 300MB on S3, partitioned by submission date, application name, update channel, application version, and build id.

As we are currently collecting v4 submissions only on pre-release channels, we store about 700 GB per day; this considering only saved_session pings as those are the ones being aggregated. Once we start receiving data on the release channel as well we are likely going to double that number.

As soon as an immutable chunk is stored on S3, an AWS lambda function adds a corresponding entry to a SimpleDB index. The index allows Spark jobs to query the set of available pings by different criteria without the need of performing an expensive scan over S3.

Spark Aggregator

A daily scheduled Spark job performs the aggregation, on the data received the day before, by the set of dimensions mentioned above. We are likely going to move from a batch job to a streaming one in the future to reduce the latency from the time a ping is stored on S3 to the time its data appears in the dashboard.

Two kinds of aggregates are produced by aggregator:

  • submission date based
  • build-id based

Aggregates by build-id computed for a given submission date have to be added to the historical ones. As long as there are submissions coming from an old build of Firefox, we will keep receiving and aggregating data for it. The aggregation of the historical aggregates with the daily computed ones (i.e. partial aggregates) happens within a PostgreSQL database.

Database

There is only one type of table within the database which is partitioned by channel, version and build-id (or submission date depending on the aggregation type).

As PostgreSQL supports natively json blobs and arrays, it came naturally to express each row just as a couple of fields, one being a json object containing a set of dimensions and the other being an array representing the histogram. Adding a new dimension in the future should be rather painless as dimensions are not represented with columns.

When a new partial aggregate is pushed to the database, PostreSQL finds the current historical entry for that combination of dimensions, if it exists, and updates the current histogram by summing to it the partially aggregated histogram. In reality a temporary table is pushed to the database that contains all partial aggregates which is then merged with the historical aggregates, but the underlying logic remains the same.

As the database is usually queried by submission date or build-id and as there are milions of partial aggregates per day deriving from the possible combinations of dimensions, the table is partitioned the way it is to allow the upsert operation to be performed as fast as possible.

API

An inverted index on the json blobs allows to efficiently retrieve, and aggregate, all histograms matching a given filtering criteria.

For example,

select aggregate_histograms(histograms) from build_id_nightly_41_20150602 where dimensions @> '{"metric": "SIMPLE_MEASURES_UPTIME", "application": "Firefox", "os": "Windows"}'::jsonb;

retrieves a list of histograms, one for each combination of dimensions matching the where clause, and adds them together producing a final histogram that represents the distribution of the uptime measure for Firefox users on the nightly Windows build created on the 2nd of June 2015.

Aggregates are made available through a HTTP API. For example, to retrieve the aggregated histogram for the GC_MS metric on Windows for build-ids of the 2015/06/15 and 2015/06/16:

curl -X GET "http://SERVICE/aggregates_by/build_id/channels/nightly/?version=41&dates=20150615,20150616&metric=GC_MS&os=Windows_NT"

 which returns

{"buckets":[0, ..., 10000],  "data":[{"date":"20150615",           "count":239459,           "histogram":[309, ..., 5047],           "label":""},          {"date":"20150616",           "count":233688,           "histogram":[306, ..., 7875],           "label":""}],  "kind":"exponential",  "description":"Time spent running JS GC (ms)"}

Dashboard

Our intern, Anthony Zhang, did a phenomenal job creating a nifty dashboard to display the aggregates. Even though it’s still under active development, it’s already functional and thanks to it we were able to spot a serious bug in the v2 aggregation pipeline.

It comes with two views, the histogram view designed for viewing distributions of measures:

histogramand an evolution view for viewing the evolution of aggregate values for measures over time:

evolutionAs we started aggregating data at the beginning of June, the evolution plot looks rightfully wacky before that date.


Categorieën: Mozilla-nl planet

Air Mozilla: Reps weekly

Mozilla planet - do, 02/07/2015 - 17:00

Reps weekly Weekly Mozilla Reps call

Categorieën: Mozilla-nl planet

Byron Jones: happy bmo push day!

Mozilla planet - do, 02/07/2015 - 07:59

the following changes have been pushed to bugzilla.mozilla.org:

  • [1174057] Authentication Delegation should add an App ID column to associate api keys with specific callbacks
  • [1163761] Allow MozReview to skip user consent screen for Authentication Delegation
  • [825946] tracking flags should be cleared when a bug is moved to a product/component where they are not valid
  • [1149593] Hovering over “Copy Summary” changes the button to a grey box
  • [1171523] Change Loop product to Hello
  • [1175928] flag changes made at the same time as a cc change are not visible without showing cc changes
  • [1175644] The cpanfile created by checksetup.pl defines the same feature multiple times, breaking cpanm
  • [1176362] [Voting] When a user votes enough to confirm an individual bug, the bug does not change to CONFIRMED properly
  • [1176368] [Voting] When updating votestoconfirm to a new value, bugs with enough votes are not moved to CONFIRMED properly
  • [1161797] Use document.execCommand(“copy”) instead of flash where it is available
  • [1177239] Please create a “Taskcluster Platform” product
  • [1144485] Adapt upstream Selenium test suite to BMO
  • [1178301] webservice_bug_update.t Parse errors: Bad plan. You planned 927 tests but ran 921
  • [1163170] Giving firefox-backlog-drivers rights to edit the Rank field anywhere it appears in bugzilla
  • [1171758] Persistent xss is possible on Firefox

discuss these changes on mozilla.tools.bmo.


Filed under: bmo, mozilla
Categorieën: Mozilla-nl planet

Mark Finkle: Random Thoughts on Management

Mozilla planet - do, 02/07/2015 - 05:11

I have ended up managing people at the last three places I’ve worked, over the last 18 years. I can honestly say that only in the last few years have I really started to embrace the job of managing. Here’s a collection of thoughts and observations:

Growth: Ideas and Opinions and Failures

Expose your team to new ideas and help them create their own voice. When people get bored or feel they aren’t growing, they’ll look elsewhere. Give people time to explore new concepts, while trying to keep results and outcomes relevant to the project.

Opinions are not bad. A team without opinions is bad. Encourage people to develop opinions about everything. Encourage them to evolve their opinions as they gain new experiences.

“Good judgement comes from experience, and experience comes from bad judgement” – Frederick P. Brooks

Create an environment where differing viewpoints are welcomed, so people can learn multiple ways to approach a problem.

Failures are not bad. Failing means trying, and you want people who try to accomplish work that might be a little beyond their current reach. It’s how they grow. Your job is keeping the failures small, so they can learn from the failure, but not jeopardize the project.

Creating Paths: Technical versus Management

It’s important to have an opinion about the ways a management track is different than a technical track. Create a path for managers. Create a different path for technical leaders.

Management tracks have highly visible promotion paths. Organization structure changes, company-wide emails, and being included in more meetings and decision making. Technical track promotions are harder to notice if you don’t also increase the person’s responsibilities and decision making role.

Moving up either track means more responsibility and more accountability. Find ways to delegate decision making to leaders on the team. Make those leaders accountable for outcomes.

Train your engineers to be successful managers. There is a tradition in software development to use the most senior engineer to fill openings in management. This is wrong. Look for people that have a proclivity for working with people. Give those people management-like challenges and opportunities. Once they (and you) are confident in taking on management, promote them.

Snowflakes: Engineers are Different

Engineers, even great ones, have strengthens and weaknesses. As a manager, you need to learn these for each person on your team. People can be very strong at starting new projects, building something from nothing. Others can be great at finishing, making sure the work is ready to release. Some excel at user-facing code, others love writing back-end services. Leverage your team’s strengthens to efficiently ship products.

“A 1:1 is your chance to perform weekly preventive maintenance while also understanding the health of your team” – Michael Lopp (rands)

The better you know your team, the less likely you will create bored, passionless drones. Don’t treat engineers as fungible, swapable resources. Set them, and the team, up for success. Keep people engaged and passionate about the work.

Further Reading

The Role of a Senior Developer
On Being A Senior Engineer
Want to Know Difference Between a CTO and a VP of Engineering?
Thoughts on the Technical Track
The Update, The Vent, and The Disaster
Bored People Quit
Strong Opinions, Weakly Held

Categorieën: Mozilla-nl planet

Karl Dubost: Web Components, Stories Of Scars

Mozilla planet - do, 02/07/2015 - 03:51

Chris Heilmann has written about Web Components.

If you want to see the mess that is the standardisation effort around web components right now in all its ugliness, Wilson Page wrote a great post on that on Mozilla Hacks. Make sure to also read the comments – lots of good stuff there.

Indeed a very good blog post to read. Then Chris went on saying:

Web Components are a great idea. Modules are a great idea. Together, they bring us hours and hours of fun debating where what should be done to create a well-performing, easy to maintain and all around extensible complex app for the web.

This is twitching in the back of my mind for the last couple of weeks. And I kind of remember a wicked pattern from 10 years ago. Enter Compound Document Formats (CDF) with its WICD (read wicked) specifications. If you think I'm silly, check the CDF FAQ:

When combining content from arbitrary sources, a number of problems present themselves, including how rendering is handled when crossing from one markup language to another, or how events propagate across the same boundaries, or how to interpret the meaning of a piece of content within an unanticipated context.

and

Simply put, a compound document is a mixture of content in any number of formats. Compound documents range from static (say, XHTML that includes a simple SVG illustration) to very dynamic (a full-fledged Web Application). A compound document may include its parts directly (such as when you include an SVG image in an XHTML file) or by reference (such as when you embed a separate SVG document in XHTML using an <object> element. There are benefits to both, and the application should determine which one you use. For instance, inclusion by reference facilitates reuse and eases maintenance of a large number of resources. Direct inclusion can improve portability or offline use. W3C will support both modes, called CDR ("compound documents by reference") and CDI ("compound documents by inclusion").

At that time, the Web and W3C, where full throttle on XML and namespaces. Now, the cool kids on the block are full HTML, JSON, polymers and JS frameworks. But if you look carefully and remove the syntax, architecture parts, the narrative is the same. And with the narratives of the battle and its scars, the Web Components sound very familiar to the Coupound Document Format.

Still by Chris

When it comes to componentising the web, the rabbit hole is deep and also a maze.

Note that not everything was lost from WICD. It helped develop a couple of things, and reimagine the platform. Stay tune, I think we will have surprises on this story. Not over yet.

Modularity has already a couple of scars when thinking about large distribution. Remember Opendoc and OLE. I still remember using Cyberdog. Fun times.

Otsukare!

Categorieën: Mozilla-nl planet

What to Look Forward to from Firefox

Mozilla Futurereleases - do, 02/07/2015 - 03:22

We created Firefox more than a decade ago with a mission to give people transparency, choice and control online. Since then, the browser has continued to evolve its critical role in how users experience the Web and control their online lives.

That’s why at Mozilla we’re always focused on one question: how do we make Firefox even better and continue to delight users? Because we are different than most tech companies and work in the open, we are sharing some experiments centered around the three focus areas of our strategy.

Firefox Pillars

 

Uncompromised Quality

The first focus area is delivering an uncompromised user experience that ensures Firefox meets the most rigorous of quality and performance standards. This commitment is evident in the strides we’re making to improve the richest Web experiences like HTML5 video playback and game performance.  We’ll also soon deliver Firefox to new platforms, such as Firefox for iOS and Windows 10, where we will provide an independent and high-performing alternative to the stock browser.

Best Of The Web

Firefox is well known for giving users complete control over their Web experience while pushing the boundaries of the “modern browser.” Today, we’re working with more partners and developers around the world to highlight innovation and offer the best of the Web in Firefox. We showed this with our new search strategy for Firefox to promote choice and innovation and with new open technologies we build based on standards including Firefox Hello, the first WebRTC in-browser video chat tool made in partnership with Telefonica. We continue to pioneer open standards including WebVR, WebGL and WebRTC to advance the Web as the development platform.

Uniquely Firefox

Earlier this year, we asked users to identify what’s different about Firefox and the results reaffirmed our view that it’s important for Firefox to be increasingly recognized for attributes such as performance, trust and quality that align with our mission.

We value that our users trust us because we protect their choices and protect their privacy. That’s why we are experimenting with improvements to private browsing and other unique features for a major release focused on these three areas that we’ll share with Firefox users later this year.

Stay tuned for more.

Categorieën: Mozilla-nl planet

Planet Mozilla Interns: Jonathan Wilde: A Project Called Gossamer

Mozilla planet - do, 02/07/2015 - 02:00

A few summers back, I worked on the Firefox Metro project. The big challenge I ran into the first summer–back when the project was at a very early stage–was figuring out how to distribute early builds.

I wanted to quickly test work-in-progress builds across different devices on my desk without having to maintain a working copy and rebuild on every device. Later on, I also wanted to quickly distribute builds to other folks, too.

I had a short-term hack based on Dropbox, batch scripts, and hope. It was successful at getting rapid builds out, but janky and unscalable.

The underlying problem space–how you build, distribute, and test experimental prototypes rapidly?–is one that I’ve been wanting to revisit for a while.

So, Gossamer

This summer, Lyre Calliope and I have had some spare time to tinker on this for fun.

We call this project Gossamer, in honor of the Gossamer Albatross, a success story in applying rapid prototyping methodology to building a human-powered airplane.

We’re working to enable the following development cycle:

  1. Build a prototype in a few hours or maybe a couple days, and at the maximum fidelity possible–featuring real user data, instead of placeholders.
  2. Share the prototype with testers as easily as sharing a web page.
  3. Understand how the prototype is performing in user testing relative to the status quo, qualitatively and quantitatively.
  4. Polish and move ideas that work into the real world in days or possibly weeks, instead of months or years.
A First Proof-of-Concept

We started by working to build a simple end-to-end demonstration of a lightweight prototyping workflow:

Starting a two-week Mozilla heartbeat-style project sprint with @hellojwilde tomorrow involving Mozilla's browser.html experiment. Excited!

— Lyre Calliope (@CaptainCalliope) May 25, 2015

(Yeah, it took longer than two weeks due to personal emergencies on my end.)

We tinkered around with a few different ways to do this.

Our proof-of-concept is a simple distribution service that wraps Mozilla’s browser.html project. It’s a little bit like TestFlight or HockeyApp, but for web browsers.

To try an experimental build, you log in via GitHub, and pick the build that you want to test…and presto!

Sequence shortened.

About the login step: When you pick an experiment, you’re picking it for all of your devices logged in via that account.

This makes cross-device feature testing a bit easier. Suppose you have a feature you want to test on different form factors because the feature is responsive to screen dimensions or input methods. Or suppose you’re building a task continuity feature that you need to test on multiple devices. Having the same experiment running on all the devices of your account makes this testing much easier.

It also enables us to have a remote one-click escape hatch in case something breaks in the experiment you’re running. (It happens to the best developers!)

To ensure that you can trust experiments on Gossamer, we integrated the login system with Mozillians. Only vouched Mozillians can ship experimental code via Gossamer.

To ship an experimental build…you click the “Ship” button. Boom. The user gets a message asking them if they want to apply the update.

And the cool thing about browser.html being a web application…is that when the user clicks the “Apply” button to accept the update…all we have to do is refresh the window.

We did some lightweight user testing by having Lyre (who hadn’t seen any of the implementation yet) step through the full install process and receive a new updated build from me remotely.

We learned a few things from this.

What We’re Working On Next

There’s three big points we want to focus on in the next milestone:

  1. Streamline every step. The build service web app should fade away and just be hidden glue around a web browser- and GitHub-centric workflow.
  2. Remove the refresh during updates. Tooling for preserving application state while making hot code changes to web applications based on React (such as browser.html!) is widely available.
  3. Make the build pipeline as fast as possible. Let’s see how short we can make the delay from pushing new code to GitHub (or editing through GitHub’s web interface) to updates appearing on your machine.

We also want to shift our mode of demo from screencasts to working prototypes.

Get Involved

This project is still at a very early stage, but if you’d like to browse the code, it’s in three GitHub repositories:

  • gossamer - Our fork of browser.html.
  • gossamer-server - The build and distribution server.
  • gossamer-larch-patches - Tweaks to Mozilla’s larch project branch containing the graphene runtime. We fixed a bug and made a configuration tweak.

Most importantly, we’d love your feedback:

There’s a lot of awesome in the pipeline. Stay tuned!

Categorieën: Mozilla-nl planet

Mozilla CEO: Virtual-reality Firefox could be game-changer - USA TODAY

Nieuws verzameld via Google - do, 02/07/2015 - 00:01

Mozilla CEO: Virtual-reality Firefox could be game-changer
USA TODAY
SAN FRANCISCO—Mozilla has started letting outside developers use a test version of its Firefox browser with new virtual-reality technology that could make surfing the web more like watching movies or playing video games. If the beta version of the ...

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: Add-ons Update – Week of 2015/07/01

Mozilla planet - do, 02/07/2015 - 00:00

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

Add-ons Forum

As we announced before, there’s a new add-ons community forum for all topics related to AMO or add-ons in general. The Add-ons category is already the most active one on the community forum, so thank you all for your contributions! The old forum is still available in read-only mode.

The Review Queues
  • Most nominations for full review are taking less than 10 weeks to review.
  • 272 nominations in the queue awaiting review.
  • Most updates are being reviewed within 8 weeks.
  • 159 updates in the queue awaiting review.
  • Most preliminary reviews are being reviewed within 10 weeks.
  • 295 preliminary review submissions in the queue awaiting review.

A number of factors have lead to the current state of the queues: increased submissions, decreased volunteer reviewer participation, and a Mozilla-wide event that took most of our attention last week. We’re back and our main focus are the review queues. We have a new reviewer on our team, who will hopefully make a difference in the state of the queues.

If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 40 Compatibility

The Firefox 40 compatibility blog post is up. The automatic compatibility validation will be run in a few weeks.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition (formerly known as Aurora) to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Extension Signing

We announced that we will require extensions to be signed in order for them to continue to work in release and beta versions of Firefox. The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions.

There’s a small change to the timeline: Firefox 40 will only warn about unsigned extensions (for all channels), Firefox 41 will disable unsigned extensions  by default unless a preference is toggled (on Beta and Release), and Firefox 42 will not have the preference. This means that we’ll have an extra release cycle before signatures are enforced by default.

Electrolysis

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running content code in a different process than browser code. This should improve responsiveness and overall stability, but it also means many add-ons will need to be updated to support this.

We will be talking more about these changes in this blog in the future. For now we recommend you start looking at the available documentation.

Categorieën: Mozilla-nl planet

Christian Heilmann: Over the Edge: Web Components are an endangered species

Mozilla planet - wo, 01/07/2015 - 22:00

Last week I ran the panel and the web components/modules breakout session of the excellent Edge Conference in London, England and I think I did quite a terrible job. The reason was that the topic is too large and too fragmented and broken to be taken on as a bundle.

If you want to see the mess that is the standardisation effort around web components right now in all its ugliness, Wilson Page wrote a great post on that on Mozilla Hacks. Make sure to also read the comments – lots of good stuff there.

Web Components are a great idea. Modules are a great idea. Together, they bring us hours and hours of fun debating where what should be done to create a well-performing, easy to maintain and all around extensible complex app for the web. Along the way we can throw around lots of tools and ideas like NPM and ES6 imports or – as Alex Russell said it on the panel: “tooling will save you”.

It does. But that was always the case. When browsers didn’t support CSS, we had Dreamweaver to create horribly nested tables that achieved the same effect. There is always a way to make browsers do what we want them to do. In the past, we did a lot of convoluted things client-side with libraries. With the advent of node and others we now have even more environments to innovate and release “not for production ready” impressive and clever solutions.

When it comes to componentising the web, the rabbit hole is deep and also a maze. Many developers don’t have time to even start digging and use libraries like Polymer or React instead and call it a day and that the “de facto standard” (a term that makes my toenails crawl up – layout tables were a “de facto standard”, so was Flash video).

React did a genius thing: by virtualising the DOM, it avoided a lot of the problems with browsers. But it also means that you forfeit all the good things the DOM gives you in terms of accessibility and semantics/declarative code. It simply is easier to write a <super-button> than to create a fragment for it or write it in JavaScript.

Of course, either are easy for us clever and amazing developers, but the fact is that the web is not for developers. It is a publishing platform, and we are moving away from that concept at a ridiculous pace.

And whilst React gives us all the goodness of Web Components now, it is also a library by a commercial company. That it is open source, doesn’t make much of a difference. YUI showed that a truckload of innovation can go into “maintenance mode” very quickly when a company’s direction changes. I have high hopes for React, but I am also worried about dependencies on a single company.

Let’s rewind and talk about Web Components

Let’s do away with modules and imports for now, as I think this is a totally different discussion.

I always loved the idea of Web Components – allowing me to write widgets in the browser that work with it rather than against it is an incredible idea. Years of widget frameworks trying to get the correct performance out of a browser whilst empowering maintainers would come to a fruitful climax. Yes, please, give me a way to write my own controls, inherit from existing ones and share my independent components with other developers.

However, in four years, we haven’t got much to show.. When we asked the very captive and elite audience of EdgeConf about Web Components, nobody raised their hand that they are using them in real products. People either used React or Polymer as there is still no way to use Web Components in production otherwise. When we tried to find examples in the wild, the meager harvest was GitHub’s time element. I do hope that this was not all we wrote and many a company is ready to go with Web Components. But most discussions I had ended up the same way: people are interested, tried them out once and had to bail out because of lack of browser support.

Web Components are a chicken and egg problem where we are currently trying to define the chicken and have many a different idea what an egg could be. Meanwhile, people go to chicken-meat based fast food places to get quick results. And others increasingly mention that we should hide the chicken and just give people the eggs leaving the chicken farming to those who also know how to build a hen-house. OK, I might have taken that metaphor a bit far.

We all agreed that XHTML2 sucked, was overly complicated, and defined without the input of web developers. I get the weird feeling that Web Components and modules are going in the same direction.

In 2012 I wrote a longer post as an immediate response to Google’s big announcement of the foundation of the web platform following Alex Russell’s presentation at Fronteers 11 showing off what Web Components could do. In it I kind of lamented the lack of clean web code and the focus on developer convenience over clarity. Last year, I listed a few dangers of web components. Today, I am not too proud to admit that I lost sight of what is going on. And I am not alone. As Wilson’s post on Mozilla Hacks shows, the current state is messy to say the least.

We need to enable web developers to use “vanilla” web components

What we need is a base to start from. In the browser and in a browser that users have and doesn’t ask them to turn on a flag. Without that, Web Components are doomed to become a “too complex” standard that nobody implements but instead relies on libraries.

During the breakout session, one of the interesting proposals was to turn Bootstrap components into web components and start with that. Tread the cowpath of what people use and make it available to see how it performs.

Of course, this is a big gamble and it means consensus across browser makers. But we had that with HTML5. Maybe there is a chance for harmony amongst competitors for the sake of an extensible and modularised web that is not dependent on ES6 availability across browsers. We’re probably better off with implementing one sci-fi idea at a time.

I wished I could be more excited or positive about this. But it left me with a sour taste in my mouth to see that EdgeConf, that hot-house of web innovation and think-tank of many very intelligent people were as confused as I was.

I’d love to see a “let’s turn it on and see what happens” instead of “but, wait, this could happen”. Of course, it isn’t that simple – and the Mozilla Hacks post explains this well – but a boy can dream, right? Remember when using HTML5 video was just a dream?

Categorieën: Mozilla-nl planet

David Burns: Who wants to be an alpha tester for Marionette?

Mozilla planet - wo, 01/07/2015 - 21:57

Are you an early adopter type? Are you an avid user of WebDriver and want to use the latest and great technology? Then you are most definitely in luck.

Marionette, the Mozilla implementation of the FirefoxDriver, is ready for a very limited outing. There is a lot of things that have not been implemented or, since we are implementing things agains the WebDriver Specification they might not have enough prose to implement (This has been a great way to iron out spec bugs).

Getting Started

At the moment, since things are still being developed and we are trying to do things with new technologies (like writing part this project using Rust) we are starting out with supporting Linux and OS X first. Windows support will be coming in the future!

Getting the driver We have binaries that you can download. For Linux and for OS X . The only bindings currently updated to work are the python bindings that are available in a branch on my fork of the Selenium project. Do the following to get it into a virtualenv:
  1. Create a virtualenv
  2. activate your virtualenv
  3. cd to where you have cloned my repository
  4. In a terminal type the following: ./go py_install
Running tests

Running tests against marionette requires that you do the following changes (which hopefully remains small)

Update the desired capability to have marionette:true and add binary:/path/to/Firefox/DeveloperEdition/or/Nightly. We are only supporting those two versions of at the moment because we have had a couple in compatible issues that we have fixed which means speaking to Marionette in the browser in the beta or release versions quite difficult.

Since you are awesome early adopters it would be great if we could raise bugs. I am not expecting everything to work but below is a quick list that I know doesn't work.

  • No support for self-signed certificates
  • No support for actions
  • No support for Proxy (but will be there soon)
  • No support logging endpoint
  • I am sure there are other things we don't remember

Thanks for being an early adopter and thanks for raising bugs as you find them!

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Ditching ElasticUtils on Input for elasticsearch-dsl-py

Mozilla planet - wo, 01/07/2015 - 20:20
What was it?

ElasticUtils was a Python library for building and executing Elasticsearch searches. I picked up maintenance after the original authors moved on with their lives, did a lot of work, released many versions and eventually ended the project in January 2015.

Why end it? A bunch of reasons.

It started at PyCon 2014, when I had a long talk with Rob, Jannis, and Erik about ElasticUtils the new library Honza was working on which became elasticsearch-dsl-py.

At the time, I knew that ElasticUtils had a bunch of architectural decisions that turned out to be make life really hard. Doing some things was hard. It was built for a pre-1.0 Elasticsearch and it would have been a monumental effort to upgrade it past the Elasticsearch 1.0 hump. The code wasn't structured particularly well. I was tired of working on it.

Honza's library had a lot of promise and did the sorts of things that ElasticUtils should have done and did them better--even at that ridiculously early stage of development.

By the end of PyCon 2014, I was pretty sure elasticsearch-dsl-py was the future. The only question was whether to gut ElasticUtils and make it a small shim on top of elasticsearch-dsl-py or end it.

In January 2015, I decided to just end it because I didn't see a compelling reason to keep it around or rewrite it into something on top of elasticsearch-dsl-py. Thus I ended it.

Now to migrate to something different.

Read more… (7 mins to read)

Categorieën: Mozilla-nl planet

Hannah Kane: Whistler Wrap-up

Mozilla planet - wo, 01/07/2015 - 19:03

What an amazing week!

Last week members of the Mozilla community met in beautiful Whistler, BC to celebrate, reflect, brainstorm, and plan (and eat snacks). While much of the week was spent in functional teams (that is, designers with designers and engineers with engineers), the Mozilla Learning Network website (known informally as “Teach”) team was able to convene for two meetings—one focused on our process, and the other on our roadmap and plans for the future.

Breakthroughs

From my perspective, the week inspired a few significant breakthroughs:

  1. The Mozilla Learning Network is one, unified team with several offerings. Those offerings can be summarized in this image: Networks, Groups, and Convenings.MLN ProgramsThe breakthrough was realizing that it’s urgent that the site reflects the full spectrum of offerings as soon as possible. We’ve adjusted our roadmap accordingly. First up: incorporate the Hive content in a way that makes sense to our audience, and provides clear pathways for engagement.
  2. Our Clubs pipeline is a bit off-balance. We have more interested Club Captains than our current (amazing) Regional Coordinators can support. This inspired an important conversation about changes to our strategy to better test out our model. We’ll be talking about how these changes are reflected on the site soon.
  3. The most important content to localize is our curriculum content. To be fair, we knew this before the work week, but it was definitely crystallized in Whistler. This gives useful shape to our localization plan.
  4. We also identified a few areas where we can begin the process of telling the full “Mozilla Learning” story. By that I mean the work that goes beyond what we call the Mozilla Learning Network—for example, we can highlight our Fellowship programs, curriculum from other teams (starting with Mozilla Science Lab!), and additional peer learning opportunities.
  5. Finally, we identified a few useful, targeted performance indicators that will help us gauge our success: 1) the # of curriculum hits, and 2) the % of site visitors who take the pledge to teach.
Site Updates

I also want to share a few site updates that have happened since I wrote last:

    • The flow for Clubs has been adjusted to reflect the “apply, connect, approve” model described in an earlier post.
    • We’ve added a Protect Your Data curriculum module with six great activities.
    • We added the “Pledge to Teach” action on the homepage. Visitors to the site can choose to take the pledge, and are then notified about an optional survey they can take. We’ll follow up with tailored offerings based on their survey responses.pledge

Questions? Ideas? Share ’em in the comments!


Categorieën: Mozilla-nl planet

Pagina's