• Àâòîðèçàöèÿ


David Lawrence: Happy BMO Push Day! rss_planet_mozilla 07-11-2018 23:46


(https://github.com/mozilla-bteam/bmo/tree/release-20181106.1)

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

  • [1503162] Approval request form is incomplete in some cases
  • [1503408] Remove extensions/PhabBugz/t/review-flags.t as no longer needed
  • [1503182] Fix data type of native bug count API return value
  • [1436619] http:// in URL field
  • [1503705] Stop serving HTML-prettyprinted JSON as REST API results
  • [1384230] Document flag_activity API
  • [1503748] Trackpad swipe navigation and mobile horizontal scrolling broken, vertical scrolling partially broken when zoomed
  • [1499503] Provide some way of dismissing the uplift form
  • [1485303] lists in component descriptions break describecomponents.cgi layout
  • [1482338] “Search Bugs” field has “cursor: pointer” style while it’s text field

discuss these changes on mozilla.tools.bmo.

https://dlawrence.wordpress.com/2018/11/07/happy-bmo-push-day-48/

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Firefox UX: How do people decide where or not to get a browser extension? rss_planet_mozilla 07-11-2018 20:50


How do people decide whether or not to get a browser extension?

The Firefox Add-ons Team works to make sure people have all of the information they need to decide which browser extensions are right for them. Past research conducted by Bill Selman and the Add-ons Team taught us a lot about how people discover extensions, but there was more to learn. Our primary research question was: “How do people decide whether or not to get a specific browser extension?”

We recently conducted two complementary research studies to help answer that big question:

  1. addons.mozilla.org (AMO) survey, with just under 7,500 respondents
  2. In-person think-aloud study with nine participants, conducted in Vancouver, BC

The survey ran from July 19, 2018 to July 26, 2018 on addons.mozilla.org (AMO). The survey prompt was displayed when visitors went to the site and was localized into 10 languages. The survey asked questions about why people were visiting the site, if they were looking to get a specific extension (and/or theme), and if so what information they used to decide to get it.

Screenshot of the survey message bar on addons.mozilla.org.

The think-aloud study took place at a Mozilla office in Vancouver, BC from July 30, 2018 to August 1, 2018. The study consisted of 45-minute individual sessions with nine participants, in which they answered questions about the browsers they use, and completed tasks on a Windows laptop related to acquiring a theme and an extension. To get a variety of perspectives, participants included three Firefox users and six Chrome users. Five of them were extension users and four were not.

Mozilla office conference room in Vancouver, where the think-aloud study took place.

What we learned about decision-making

Now we share some key results from both the survey and the think-aloud study.

People use social proof on the extension’s product page

Ratings, reviews, and number of users proved important for making a decision to get the extension in both the survey and think-aloud study. Think-aloud participants used these metrics as a signal that an extension was good and safe. All except one think-aloud participant used this “social proof” before installing an extension. The importance of social proof was backed up by the survey responses where ratings, number of users, and reviews were among the top pieces of information used.

Screenshot of Facebook Container’s page on addons.mozilla.org with the “social proof” outlined: number of users, number of reviews, and rating.
AMO survey responses to “Think about the extension(s) you were considering getting. What information did you use to decide whether or not to get the extension?”

People use social proof outside of AMO

Think-aloud participants mentioned using outside sources to help them decide whether or not to get an extension. Outside sources included forums, advice from “high authority websites,” and recommendations from friends. The same result is seen among the survey respondents, where 40.6% of respondents used an article from the web and 16.2% relied on a recommendation from a friend or colleague. This is consistent with our previous user research, where participants used outside sources to build trust in an extension.

Screenshot of an example outside source: TechCrunch article about Facebook Container extension.
AMO survey responses to “What other information did you use to decide whether or not to get an extension?”

People use the description and extension name

Almost half of the survey respondents use the description to make a decision about the extension. While the description was the top piece of content use, we also see that over one-third of survey respondents use screenshots and the extension summary (“Description

×èòàòü äàëåå...
êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè

Mozilla VR Blog: Lessons Learned while Designing for the Immersive Web rss_planet_mozilla 07-11-2018 20:00


Lessons Learned while Designing for the Immersive Web

In this Q&A, independent UX designer and creative catalyst Nadja Haldimann talks about how she approached working with Mozilla on the new Firefox Reality browser for virtual reality (VR). Before launch, Nadja and Mozilla’s Mixed Reality team worked with Seattle-based BlinkUX to do user testing. Here’s what they learned, and the solutions they found, to create a web browser that people can use strapped to their faces.

How difficult is it to design for an immersive, 3D environment, compared to 2D software?
It’s not necessarily more difficult – all the same design principles still apply – but it is quite different. One of the things that you have to account for is how the user perceives space in a headset – it seems huge. So instead of designing for a rectangular window inside a rectangular display, you’re suspending a window in what looks to be a very large room. The difficulty there is that people want to fill that room with a dozen browser windows, and maybe have a YouTube video, baseball game or stock ticker running in the background. But in reality, we only have these 2-inch screens to work with, one for each eye, and the pixels of just half a cell phone screen. But the perception is it’s 1,000 times bigger than a desktop. They think they’re in a movie theater.

OK, so here you have this massive 3D space. You can put anything in there you want. What did you create?
That was a really big question for us: what is the first thing people see when they open the browser? We built two things for the Firefox Reality home page. First, we worked with digital artists to create scenes users could choose as the background, because, just like on a 2D desktop browser, we found people want to customize their browser window with themes and images that mean something to them. The goal was to create environments that were grounding and inviting, especially for people who might be experiencing an immersive environment for the first time.

Lessons Learned while Designing for the Immersive Web
Magical cave, created by Jasmin Habezai-Fekri

Lessons Learned while Designing for the Immersive Web
Alpine meadow created by Lexie Mason-Davis.

Second, we created a content feed to help people find great new 3D experiences on the web. Immersive media is just getting off the ground, so content is somewhat limited today but growing quickly. The content feed showcases quality, family-friendly content that supports the WebVR API, so it’s easy to view on multiple devices.

Lessons Learned while Designing for the Immersive Web

What kinds of limitations or challenges did you run into while designing the browser’s UI?
In VR, the most important thing is to make the user comfortable. In the past, a significant number of people have had trouble with nausea and motion sickness — and women are more susceptible, according to research. You can avoid that by delivering a smooth, responsive experience, where the display can render the content very, very quickly. The best experience is one where the user actually forgets they’re in a VR environment. They’re happy spending time there and they want to keep exploring.

The first problem we ran into was that people felt like they were floating above the floor. Part of that was because we had the camera height set to 5’ 6”, which is roughly the height of an adult standing up. But in user testing, people were sitting down. So there was a disconnect between what people were seeing in the headset and where they knew their physical bodies to be. The other part was that we were using colors to indicate floor, without enough texture. It’s textures that let our brains identify distance in VR. We created low poly environments with limited textures, so people could perceive the floor, and that helped people feel more comfortable in the environment.

Another surprise was how people perceive an app window size in the immersive environment. In 2D, people talk about making a window “smaller” or “bigger”, and everyone knows how to change that. In 3D, users were more likely to say they wanted to put a window “farther away” or

×èòàòü äàëåå...
êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Mozilla Addons Blog: Friend of Add-ons: Jyotsna Gupta rss_planet_mozilla 07-11-2018 18:55


https://blog.mozilla.org/addons/2018/11/07/friend-of-add-ons-jyotsna-gupta/

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Mozilla Addons Blog: Friend of Add-ons: Jyotsna Gupta rss_planet_mozilla 07-11-2018 18:55


https://blog.mozilla.org/addons/2018/11/07/friend-of-add-ons-jyotsna-gupta/

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Hacks.Mozilla.Org: Cross-language Performance Profile Exploration with speedscope rss_planet_mozilla 07-11-2018 18:24


https://hacks.mozilla.org/2018/11/cross-language-performance-profile-exploration-with-speedscope/

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Hacks.Mozilla.Org: Cross-language Performance Profile Exploration with speedscope rss_planet_mozilla 07-11-2018 18:24


https://hacks.mozilla.org/2018/11/cross-language-performance-profile-exploration-with-speedscope/

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Daniel Stenberg: Get the CA cert for curl rss_planet_mozilla 07-11-2018 09:58


When you use curl to communicate with a HTTPS site (or any other protocol that uses TLS), it will by default verify that the server is signed by a trusted Certificate Authority (CA). It does this by checking the CA bundle it was built to use, or instructed to use with the --cacert command line option.

Sometimes you end up in a situation where you don't have the necessary CA cert in your bundle. It could then look something like this:

$ curl https://example.com/
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

Do not disable!

A first gut reaction could be to disable the certificate check. Don't do that. You'll just make that end up in production or get copied by someone else and then you'll spread the insecure use to other places and eventually cause a security problem.

Get the CA cert

I'll show you four different ways to fix this.

1. Update your OS CA store

Operating systems come with a CA bundle of their own and on most of them, curl is setup to use the system CA store. A system update often makes curl work again.

This of course doesn't help you if you have a self-signed certificate or otherwise use a CA that your operating system doesn't have in its trust store.

2. Get an updated CA bundle from us

curl can be told to use a separate stand-alone file as CA store, and conveniently enough curl provides an updated one on the curl web site. That one is automatically converted from the one Mozilla provides for Firefox, updated daily. It also provides a little backlog so the ten most recent CA stores are available.

If you agree to trust the same CAs that Firefox trusts. This is a good choice.

3. Get it with openssl

Now we're approaching the less good options. It's way better to get the CA certificates via other means than from the actual site you're trying to connect to!

This method uses the openssl command line tool. The servername option used below is there to set the SNI field, which often is necessary to tell the server which actual site's certificate you want.

$ echo quit | openssl s_client -showcerts -servername server -connect server:443 > cacert.pem

A real world example, getting the certs for daniel.haxx.se and then getting the main page with curl using them:

$ echo quit | openssl s_client -showcerts -servername daniel.haxx.se -connect daniel.haxx.se:443 > cacert.pem

$ curl --cacert cacert.pem https://daniel.haxx.se
4. Get it with Firefox

Suppose you're browsing the site already fine with Firefox. Then you can do inspect it using the browser and export to use with curl.

Step 1 - click the i in the circle on the left of the URL in the address bar of your browser.

Step 2 - click the right arrow on the right side in the drop-down window that appeared.

Step 3 - new contents appeared, now click the "More Information" at the bottom, which pops up a new separate window...

Step 4 - Here you get security information from Firefox about the site you're visiting. Click the "View Certificate" button on the right. It pops up yet another separate window.

Step 5 - in this window full of certificate information, select the "Details" tab...

Step 6 - when switched to the details tab, there's the certificate hierarchy shown at the top and we select the top choice there. This list will of course look different for different sites

×èòàòü äàëåå...
êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Nicholas Nethercote: How to speed up the Rust compiler in 2018: NLL edition rss_planet_mozilla 06-11-2018 22:48


Niko Matsakis recently blogged about the Rust compiler’s new borrow checker, which implements non-lexical lifetimes (NLL). The new borrow checker is a really nice improvement to Rust, because it accepts many sound programs that the old borrow checker rejected.

In the blog post, Niko wrote briefly about the performance of the new borrow checker.

Finally, those of you who read the previous posts may remember that the performance of the NLL checker was a big stumbling block. I’m happy to report that the performance issues were largely addressed: there remains some slight overhead to using NLL, but it is largely not noticeable in practice, and I expect we’ll continue to improve it over time.

This paragraph is true, but glosses over a lot of details! This post will be about my contributions to this performance work.

Wins

Before I describe individual improvements, it’s worth mentioning that the new borrow checker uses bitsets (1D) and bit matrices (2D) heavily. A number of my wins involved these data structures.

#51869: This PR changed some code so that it overwrote an existing dense bitset rather than replacing it with a newly created one of the same size, reducing instruction counts for most benchmarks, the best by 1.5%.

#51870: This PR reused a structure containing two bitsets rather than recreating it afresh for every statement in a basic block, reducing instruction counts for numerous benchmarks, the best by 1%.

#52250: The compiler has a SparseBitMatrix type. Rows were added on demand, and each row was implemented as a sparse bitset using a BTreeMap. In practice, many of the rows were relatively dense, with 10–90% of the bits being set. This PR changed SparseBitMatrix to use a dense representation for rows, reducing instruction counts on one benchmark by 33% and by 1% on a few others. The PR had a mixed effect on memory usage, increasing the peak on some benchmarks and reducing it on others. (Never fear! #54318 below ended up fixing the regressions.)

#52342: This PR avoided a bunch of allocations in Canonicalizer methods, reducing instruction counts on numerous benchmarks, the best by 2%.

#53383: Further profiling showed that some dense bitsets were large, but had very few bits set within them, so the dense representation was wasteful. This PR implemented a new hybrid bitset type that uses a sparse representation for bitsets with up to 8 bits set and switches to a dense representation beyond that, and used it to replace dense bitsets in several places, reducing instruction counts on the five slowest benchmarks by 55%, 21%, 16%, 10% and 9%, and reducing peak memory usage of three benchmarks by 53%, 33%, and 9%.

#53513: This PR force-inlined a function at one hot callsite, reducing instruction counts on two benchmarks by 1%.

#53551: This PR avoided some clone calls, reducing instruction counts for one benchmark by 0.5%.

#53733: This PR added special handling for a very common and simple case in unroll_place, reducing the instruction counts on one benchmark by 25%.

#53942: A function called precompute_borrows_out_of_scope does a traversal of one or more basic blocks. In order to detect whether a basic block had been previously visited, it recorded the ID of every visited statement in a hash table. Some basic blocks can have many statements, resulting in many hash table lookups. This PR changed the code to record the ID of visited basic blocks in the hash table instead of visited statements — trickier than it sounds because the analysis can start in the middle of a basic block, in which case the first half might need to be eventually visited — reducing instruction counts on one benchmark by 60%.

#54211: Liveness analysis created an array that could get very large. Each element in the array was a struct containing

×èòàòü äàëåå...
êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Firefox Test Pilot: Understanding users’ wants and needs for linking Cloud Storage providers rss_planet_mozilla 05-11-2018 23:34


Note: this was written by two members of the Test Pilot team: Punam and Teon.

For our Cloud Storage experiment we sampled a small portion of Firefox users to gauge interest in saving downloads directly to their existing cloud storage, allowing the downloads to be accessible from all their devices. We used the Shield platform for this study.

Using learnings from the previous study, the Phase 2 study rolled out the Cloud Storage extension with a simpler and less disruptive interface by moving the option to save downloads into the Download Panel.

Key features of this experiment:

  • In this study, users of desktop cloud storage providers were prompted inside the download panel to use their existing cloud storage for saving files to the cloud. In the example below, the user already has Dropbox and Google Drive on their computer, so we gave both options.
  • Users of desktop cloud storage providers were able to use the context menu to select and move downloaded files to their preferred cloud storage.
  • Downloads in ‘Download Panel’ and ‘Download History’ were annotated with storage provider icon for users to easily differentiate cloud saved files from local downloads.
  • Users selecting cloud storage as a download option were able to view/update setting under Downloads in about:preferences.

The Cloud Storage Phase 2 Study was a two week study, launching at the end of June. It targeted 1% of Firefox 60+ release users with the en-US locale. Users who were a part of this study were prompted to change their defaults. If they said no or didn’t reply, no changes were made.

Key findings of the study

Graphs

  • The types of Cloud Storage providers:
  • Given the option, would you choose to keep this feature in the browser?
  • 10.05% of users in the experimental condition opted-in to have the WebExtension change the default download location to their Cloud Storage provider.
  • 0.06% of users in the experimental condition used the `Move Download` feature.

For detailed findings, you can visit this URL.

Lessons Learned

In the download manager, the ‘Move Download To’ feature was only discoverable by right-click and we should have made it easier to find.

We targeted 1% of Release Firefox, but only a small portion of those users had cloud storage providers, and even a smaller portion opted in to our study. It would have been nice to be able to more accurately target people with cloud storage providers.


Understanding users’ wants and needs for linking Cloud Storage providers was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.

https://medium.com/firefox-test-pilot/understanding-users-wants-and-needs-for-linking-cloud-storage-providers-d9a300269820?source=rss----46b1a2ddb811---4

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Gregory Szorc: Absorbing Commit Changes in Mercurial 4.8 rss_planet_mozilla 05-11-2018 12:25


Every so often a tool you use introduces a feature that is so useful that you can't imagine how things were before that feature existed. The recent 4.8 release of the Mercurial version control tool introduces such a feature: the hg absorb command.

hg absorb is a mechanism to automatically and intelligently incorporate uncommitted changes into prior commits. Think of it as hg histedit or git rebase -i with auto squashing.

Imagine you have a set of changes to prior commits in your working directory. hg absorb figures out which changes map to which commits and absorbs each of those changes into the appropriate commit. Using hg absorb, you can replace cumbersome and often merge conflict ridden history editing workflows with a single command that often just works. Read on for more details and examples.

Modern version control workflows often entail having multiple unlanded commits in flight. What this looks like varies heavily by the version control tool, standards and review workflows employed by the specific project/repository, and personal preferences.

A workflow practiced by a lot of projects is to author your commits into a sequence of standalone commits, with each commit representing a discrete, logical unit of work. Each commit is then reviewed/evaluated/tested on its own as part of a larger series. (This workflow is practiced by Firefox, the Git and Mercurial projects, and the Linux Kernel to name a few.)

A common task that arises when working with such a workflow is the need to incorporate changes into an old commit. For example, let's say we have a stack of the following commits:

$ hg show stack
  @  1c114a ansible/hg-web: serve static files as immutable content
  o  d2cf48 ansible/hg-web: synchronize templates earlier
  o  c29f28 ansible/hg-web: convert hgrc to a template
  o  166549 ansible/hg-web: tell hgweb that static files are in /static/
  o  d46d6a ansible/hg-web: serve static template files from httpd
  o  37fdad testing: only print when in verbose mode
 /   (stack base)
o  e44c2e (@) testing: install Mercurial 4.8 final

Contained within this stack are 5 commits changing the way that static files are served by hg.mozilla.org (but that's not important).

Let's say I submit this stack of commits for review. The reviewer spots a problem with the second commit (serve static template files from httpd) and wants me to make a change.

How do you go about making that change?

Again, this depends on the exact tool and workflow you are using.

A common workflow is to not rewrite the existing commits at all: you simply create a new fixup commit on top of the stack, leaving the existing commits as-is. e.g.:

$ hg show stack
  o  deadad fix typo in httpd config
  o  1c114a ansible/hg-web: serve static files as immutable content
  o  d2cf48 ansible/hg-web: synchronize templates earlier
  o  c29f28 ansible/hg-web: convert hgrc to a template
  o  166549 ansible/hg-web: tell hgweb that static files are in /static/
  o  d46d6a ansible/hg-web: serve static template files from httpd
  o  37fdad testing: only print when in verbose mode
 /   (stack base)
o  e44c2e (@) testing: install Mercurial 4.8 final

When the entire series of commits is incorporated into the repository, the end state of the files is the same, so all is well. But this strategy of using fixup commits (while popular - especially with Git-based tooling like GitHub that puts a larger emphasis on the end state of changes rather than the individual commits) isn't practiced by all projects. hg absorb will not help you if this is your workflow.

A popular variation of this fixup commit workflow is to author a new commit then incorporate this commit into a prior commit. This typically involves the following actions:



$ hg commit


$ hg histedit


OR



$ git add 
$ git commit


$ git rebase --interactive

Essentially, you produce a new commit. Then you run a history editing command. You then tell that history editing command what to do (e.g. to squash or fold one commit into another), that command performs work and produces a set of rewritten commits.

In simple cases, you may make a simple

×èòàòü äàëåå...
êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Mozilla Localization (L10N): L10n Report: November edition rss_planet_mozilla 05-11-2018 10:19


https://blog.mozilla.org/l10n/2018/11/05/l10n-report-november-edition-2/

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Chris Pearce: On learning Go and a comparison with Rust rss_planet_mozilla 05-11-2018 05:28


I spoke at the AKL Rust Meetup last month (slides) about my side project doing data mining in Rust. There were a number of engineers from Movio there who use Go, and I've been keen for a while to learn Go and compare it with Rust and Python for my data mining side projects, so that inspired me to knuckle down and learn Go.

Go is super simple. I was able to learn the important points in a couple of evenings by reading GoByExample, and I very quickly had an implementation of the FPGrowth algorithm in Go up and running. For reference, I also have implementations of FPGrowth in Rust, PythonJava and C++

As a language, Go is very simple. The language lacks many of the higher level constructs of other modern languages, but the lack of these make it very easy to learn, straightforward to use, and easy to read and understand. It feels similar to Python. There's little hidden functionality; you can't overload operators for example, and there's no generics or macros, so the implementation for everything has to be rewritten for every type. This gets tedious, but it does at least mean the implementation for everything is simple and explicit, the code right in front of you.

I also really miss the functional constructs that are built into many other languages, like mapping a function over a sequence, filter, any, all, etc. With Go, you need to reimplement these yourself, and because there's no generics (yet), you need to do it for every type you want to use these on. The lack of generics is also painful when writing custom containers.

Not being able to key a map with a struct containing a slice was a nuisance for my problem domain; I ended up having to write a custom tree-set data structure due to this; though it was very easy to write thanks to in built maps. Whereas Rust, or even Java, has traits/functions you can implement to ensure things can be hashed.

The package management for Go feels a bit tacked on; requiring all Go projects to be in a GO_PATH seems a consequence of not having a tool the equal of Rust's Cargo coupled with something like crates.io.

And Go's design decision to use the case of a symbol's first letter to express whether that symbol is public or private is annoying. I have a long standing habit of using foo as the name for a single instance of type Foo, but that pattern doesn't work in Go. The consequence of this design choice is it leads programmers to using lots of non-descriptive names for things. Like single letter variable names. Or the dreaded myFoo.

The memory model of Go is simple, and again I think the simplicity is a strength of the language. Go uses escape analysis to determine whether a value escapes outside of a scope, and moves such values to the heap if so. Go also dynamically grows goroutines' stacks, so there's no stack overflow. Go is garbage collected, so you don't have to worry about deallocating things.

I found that thinking of values as being on the heap or stack wasn't a helpful mental model with Go. Once I started to think of variables as references to values and values being shared when I took the address (via the & operator), the memory model clicked.

I think Go's simple memory model and syntax make it a good candidate as a language to teach to beginner programmers, more so than Rust.

The build times are impressively fast, particularly on an incremental build. After the initial build of my project, I was getting build times to fast to perceive on my 2015 13"
×èòàòü äàëåå...
êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
The Servo Blog: This Week In Servo 118 rss_planet_mozilla 05-11-2018 03:30


In the past week, we merged 75 PRs in the Servo organization’s repositories.

Planning and Status

Our roadmap is available online, including the overall plans for 2018.

This week’s status updates are here.

Exciting Work in Progress

Notable Additions

  • eijebong updated hyper to a version that uses async I/O.
  • ferjm updated the gstreamer binaries to support more media types on Android.
  • notriddle fixed a web compatibility problem with assigning names to iframes.
  • ajeffrey created a Magic Leap port of Servo.
  • CYBAI avoided a crash when unloading browser contexts.
  • jdm worked around an incorrectly implemented GL API on older Android devices.
  • paulrouget added a shutdown synchronization mechanism for the Android port.
  • ferjm implemented byte-range seeking for file URLs.
  • jdm made it possible to disable bluetooth support at the platform level.

New Contributors

  • Sean Voisen

Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!

https://blog.servo.org/2018/11/05/twis-118/

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
David Humphrey: Observations on Hacktoberfest 2018 rss_planet_mozilla 04-11-2018 04:53


This term I'm teaching two sections of our Topics in Open Source Development course. The course aims to take upper-semester CS students into open source projects, and get them working on real-world software.

My usual approach is to put the entire class on the same large open source project. I like this method, because it means that students can help mentor each other, and we can form a shadow-community off to the side of the main project. Typically I've used Mozilla as a place to do this work.

However, this term I've been experimenting with having students work more freely within open source projects on GitHub in general. I also wanted to try encouraging students to work on Hacktoberfest as part of their work.

Hacktoberfest

Hacktoberfest is a yearly event sponsored by DigitalOcean, Twilio, and GitHub, which encourages new people to get involved in open source. Submit five pull requests on GitHub during October, get a T-Shirt and stickers. This year, many companies have joined in and offered to also give extra swag or prizes if people fix bugs in their repos (e.g., Microsoft).

Some of my students have done Hacktoberfest in the past and enjoyed it, so I thought I'd see what would happen if I got all my students involved. During the month of October, I asked my students to work on 1 pull request per week, and also to write a blog post about the experience, what they learned, what they fixed, and to share their thoughts.

Results

Now that October has ended, I wanted to share what I learned by having my students do this. During the month I worked with them to answer questions, support their problems with git and GitHub, explain build failures on Travis, intervene in the comments of pull requests, etc. Along the way I got to see what happens when a lot of new people suddenly get thrust into open source.

You can find all the PRs and blog posts here, but let me take you through some raw numbers and interesting facts:

  • 61 Students began Hacktoberfest and 91% were able to finish the required 5 PRs, three completed 6, and one student completed 10.
  • 307 Pull Requests were made to 180 repositories. As of Nov 1, 53% of these have already been merged.
  • 42,661 lines of code were added, 10,387 lines deleted in 3,465 files. Small changes add up.
  • The smallest PR was a fix for a single character, the largest added 10K lines by refactoring an iOS project to use a new Swift networking library (NOTE: there were a few really large PRs which I haven't included, because they were mostly generated files in the form of node_modules). Many PRs fixed bugs by simply deleting code. "Sir, are you sure this counts?" Yes, it most certainly does.

One of the things I was interested in seeing was which languages the students would choose to work in, when given the choice. As a result, I tried to keep track of the languages being used in PRs. In no particular order:

  • Rust
  • Swift
  • Scala
  • JavaScript
  • React
  • node.js
  • Markdown
  • PHP
  • Lua
  • Localization files (many types, many, many Natural languages)
  • JSON
  • C#
  • C++
  • Java
  • Go
  • Ruby
  • Python
  • HTML, CSS
  • Solidity (Etherium)

I was also interested to see which projects the students would join. I'll discuss this more broadly below, but here are some of the more notable projects to which I saw the students submit fixes:

  • TravisCI
  • Microsoft VSCode
  • Mozilla Focus for iOS
  • Mozilla Addons (Frontend)
  • Brave for iOS
  • Handbrake
  • Ghost (blog platform)
  • Pandas
  • Keras
  • Jest
  • Monaco Editor
  • Microsoft (documentation for various projects)
  • Auth0
  • 30 Seconds of Code
  • Angular Material
  • Oh my zsh

A number of students did enough work in the project that they were asked to become collaborators. In two cases, the students were

×èòàòü äàëåå...
êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Mozilla VR Blog: How to Run a UX XR Study rss_planet_mozilla 01-11-2018 02:23


How to Run a UX XR Study

This article is part four of the series that reviews the user testing conducted on Hubs by Mozilla, a social XR platform. Previous posts in this series have covered insights related to accessibility, user experience, and environmental design. The objective of this final post is to give an overview of how the Extended Mind and Mozilla collaborated to execute this study and make recommendations for best practices in user research on cross platform (2D and XR) devices.

PARTICIPANTS WILL MAKE OR BREAK THE STUDY

Research outcomes are driven by participant quality so plan to spend a lot of time up front recruiting. If you don’t already have defined target users, pick a user profile and recruit against that. In this study, Jessica Outlaw and Tyesha Snow of The Extended Mind sought people who were tech savvy enough to use social media and communicate on smartphones daily, but did not require that they owned head-mounted displays (HMDs) at home.

The researchers’ approach was to recruit for the future user of Hubs by Mozilla, not the current user who might be an early adopter. Across the ten participants in the study, a broad range of professions were represented (3D artist, engineer, realtor, psychologist, and more), which in this case was ideal because Hubs exists as a standalone product. However, if Hubs were in an earlier stage where only concepts or wireframes could be shown to users, it would have been better to include people with VR expertise because they could more easily imagine the potential it.

In qualitative research, substantial insights can be generated from between six and twelve users. Beyond twelve users, there tends to be redundancy in the feedback, which doesn’t justify the extra costs of recruiting and interviewing those folks. In general, there is more value in running two smaller studies of six people at different iterations of product development, rather than just one study with a larger sample size. In this study, there were ten participants, who provided both diversity of viewpoints and enough consistency that strong themes emerged.

The researchers wanted to test Hubs’ multi-user function by recruiting people to come in pairs. Having friends and romantic partners participate in the study allowed The Extended Mind to observe authentic interactions between people. While many of them were new to XR and some were really impressed by the immersive nature of the VR headset, they were grounded in a real experience of talking with a close companion

For testing a social XR product, consider having people come in with someone they already know. Beyond increasing user comfort, there is another advantage in that it was more efficient for the researchers. They completed research with ten people in a single day, which is a lot in user testing.

Summary of recruiting recommendations

  • Recruit participants who represent the future target user of your product (identifying user profiles is often a separate research project in user-centered design)
  • The farther along the product is in development, the less technologically sophisticated users need to be
  • You can achieve important insights with as few as six participants.
  • To test social products, consider bringing in people in pairs. This can also be efficient for the researchers.

COLLECTING DATA

It’s important to make users feel welcome when they arrive. Offer them water or snacks. Pay them an honorarium for their time. Give them payment before the interviews begin so that they know their payment is not conditional on them saying nice things about your product. In fact, give them explicit permission to say negative things about the product. Participants tend to want to please researchers so let them know you want their honest feedback. Let them know up front that they can end the study, especially if they become uncomfortable or motion sick.

The Extended Mind asked people to sign a consent form for audio, video, and screen recording. All forms should give people the choice to opt out from recordings.

In the Hubs by Mozilla study, the format of each interview session was:

  • Welcome and pre-Hubs interview on how participants use technology (20 min)
  • Use Hubs on 3 different devices (40 min)
  • Closing interview on their impressions of Hubs (30 min)

Pairs were together for the opening and closing interviews, but

×èòàòü äàëåå...
êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Daniel Pocock: RHL'19 St-Cergue, Switzerland, 25-27 January 2019 rss_planet_mozilla 01-11-2018 00:06


(translated from original French version)

The Rencontres Hivernales du Libre (RHL) (Winter Meeting of Freedom) takes place 25-27 January 2019 at St-Cergue.

Swisslinux.org invites the free software community to come and share workshops, great meals and good times.

This year, we celebrate the 5th edition with the theme «Exploit».

Please think creatively and submit proposals exploring this theme: lectures, workshops, performances and other activities are all welcome.

RHL'19 is situated directly at the base of some family-friendly ski pistes suitable for beginners and more adventurous skiers. It is also a great location for alpine walking trails.

Why, who?

RHL'19 brings together the forces of freedom in the Leman basin, Romandy, neighbouring France and further afield (there is an excellent train connection from Geneva airport). Hackers and activists come together to share a relaxing weekend and discover new things with free technology and software.

If you have a project to present (in 5 minutes, an hour or another format) or activities to share with other geeks, please send an email to rhl-team@lists.swisslinux.org or submit it through the form.

If you have any specific venue requirements please contact the team.

You can find detailed information on the event web site.

Please ask if you need help finding accommodation or any other advice planning your trip to the region.

https://danielpocock.com/rhl19-st-cergue-switzerland

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Daniel Stenberg: curl 7.62.0 MOAR STUFF rss_planet_mozilla 31-10-2018 09:55


This is a feature-packed release with more new stuff than usual.

Numbers

the 177th release
10 changes
56 days (total: 7,419)

118 bug fixes (total: 4,758)
238 commits (total: 23,677)
5 new public libcurl functions (total: 80)
2 new curl_easy_setopt() options (total: 261)

1 new curl command line option (total: 219)
49 contributors, 21 new (total: 1,808)
38 authors, 19 new (total: 632)
  3 security fixes (total: 84)

Security

New since the previous release is the dedicated curl bug bounty program. I'm not sure if this program has caused any increase in reports as it feels like a little too early to tell.

CVE-2018-16839 - an integer overflow case that triggers on 32 bit machines given extremely long input user name argument, when using POP3, SMTP or IMAP.

CVE-2018-16840 - a use-after-free issue. Immediately after having freed a struct in the easy handle close function, libcurl might write a boolean to that struct!

CVE-2018-16842 - is a vulnerability in the curl command line tool's "warning" message display code which can make it read outside of a buffer and send unintended memory contents to stderr.

All three of these issues are deemed to have low severity and to be hard to exploit.

New APIs!

We introduce a brand new URL API, that lets applications parse and generate URLs, using libcurl's own parser. Five new public functions in one go there! The link goes to the separate blog entry that explained it.

A brand new function is introduced (curl_easy_upkeep) to let applications maintain idle connections while no transfers are in progress! Perfect to maintain HTTP/2 connections for example that have a PING frame that might need attention.

More changes

Applications using libcurl's multi interface will now get multiplexing enabled by default, and HTTP/2 will be selected for HTTPS connections. With these new changes of the default behavior, we hope that lots of applications out there just transparently and magically will start to perform better over time without anyone having to change anything!

We shipped DNS-over-HTTPS support. With DoH, your internet client can do secure and private name resolves easier. Follow the link for the full blog entry with details.

The good people at MesaLink has a TLS library written in rust, and in this release you can build libcurl to use that library. We haven't had a new TLS backend supported since 2012!

Our default IMAP handling is slightly changed, to use the proper standards compliant "UID FETCH" method instead of just "FETCH". This might introduce some changes in behavior so if you're doing IMAP transfers, I advice you to mind your step into this upgrade.

Starting in 7.62.0, applications can now set the buffer size libcurl will use for uploads. The buffers used for download and upload are separate and applications have been able to specify the download buffer size for a long time already and now they can finally do it for uploads too. Most applications won't need to bother about it, but for some edge case uses there are performance gains to be had by bumping this size up. For example when doing SFTP uploads over high latency high bandwidth connections.

curl builds that use libressl will now at last show the correct libressl version number in the "curl -V" output.

Deprecating legacy

CURLOPT_DNS_USE_GLOBAL_CACHE is deprecated! If there's not a massive complaint uproar, this means this option will effectively be made pointless in April 2019. The global cache isn't thread-safe and has been called obsolete in the docs since 2002!

HTTP pipelining support is deprecated! Starting in this version, asking for pipelining will be

×èòàòü äàëåå...
êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Mozilla B-Team: happy bmo push day! rss_planet_mozilla 31-10-2018 00:28


happy bmo push day!

release tag

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

  • [1487171] Allow setting bug flags when creating/updating attachment with API
  • [1497077] Convert links, image/iframe sources, form actions to absolute path
  • [1469733] Fix scrolling glitch on Safari
  • [1496057] Security bugs report october update
  • [1499905] Update BMO enter bug workflow to include Data Science
  • [1370855] Add a…

View On WordPress

https://mozilla-bteam.tumblr.com/post/179599079038

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè
Mozilla B-Team: happy bmo push day! rss_planet_mozilla 31-10-2018 00:28


happy bmo push day!

release tag

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

  • [1487171] Allow setting bug flags when creating/updating attachment with API
  • [1497077] Convert links, image/iframe sources, form actions to absolute path
  • [1469733] Fix scrolling glitch on Safari
  • [1496057] Security bugs report october update
  • [1499905] Update BMO enter bug workflow to include Data Science
  • [1370855] Add a…

View On WordPress

https://mozilla-bteam.tumblr.com/post/179599079038

êîììåíòàðèè: 0 ïîíðàâèëîñü! ââåðõ^ ê ïîëíîé âåðñèè