Planet Firefox Mobile

May 14, 2012 10:08 PM

I've heard the phrase "web scale" come up a few times recently, and it's kind of been simmering in my mind, so here are some random thoughts to help exorcise it.

Web scale is huge. When you scale things up to the web, you're often scaling things up by a factor of millions or more. There's a huge difference when you're dealing with things at that scale. Events that have a one-in-a-million chance of happening actually do start happening when you're at web scale. This is both bad and good.

Companies like Google and Facebook like operating at web scale, because it gives them a lot of power. They are able to take little itty-bitty pieces of information about their users that individually are almost worthless, but in aggregate is worth billions of dollars. Their users pay a cost in terms of privacy; many do this by choice. However, there's also a different cost that is paid by a few, the cost of a one-in-a-million catastrophic event. If Google accidentally loses the data of .0001% of their users, they might not care very much or try very hard to fix it. At web scale, though, that .0001% is a lot of users, and those users basically get shafted. That's why web scale is scary.

But the same one-in-a-million events also work in our favour. There are lots of stories out there of somebody needing some help, reaching out on the web, and finding it. People separated by continents coming together to work towards a common goal. That, too, is a function of web scale. It may not be easy to find someone on your street or in your town who shares your particular goal, but on the web, you can find those people and make things happen. That's why web scale is good.

The web reminds me of the famous quote by Archimedes: "Give me a place to stand and with a lever I will move the whole world." The web is like that lever; it provides the potential to move the world, but only to those who can wield it. Personally I don't believe that such power should be concentrated into the hands of a few. The web should remain accessible to everyone, regardless of who they are, where they're from, the language they speak, or anything else. It's the only way to prevent an imbalance of power and keep the playing field even.

Easier said than done, though. At web scale the only way to accomplish that is to empower the users themselves. If you put out a product for five individual users, it's easy enough to customize it to suit their individual needs. If you put out a product for five million users, it's impossible. Even a well-understood thing like language localization becomes hard at web scale, because you might find that one of your five million users only speaks languages you don't do localization in. The only way to do it is to give your users the power to do it themselves.

That's why maintaining open standards and decentralizing systems is important. They shift the balance of power back to the users where it's sorely needed. If you're building a product, they let you avoid forcing your users into becoming victims of your scale. It's just one of the many reasons I'm glad I work at a place like Mozilla, where ideas like user sovereignty are built right into our mission and manifesto. But Mozilla operates at web scale too, and we have to be careful that we don't end up victims of our own success, by growing too big too fast and forgetting that scale changes everything.

May 14, 2012 07:15 PM

Logs and screenshots really help when looking at bugs for developers as well as QA.  There are free apps out there that will do these things.

For logs, there is an app called alogcat ( https://play.google.com/store/apps/details?id=org.jtb.alogcat&hl=en )

that will allow you to share or save your logs after you hit the menu button.

As for taking screenshots, it’s gotten even easier than having to install android sdk.  There are free apps out there on the market such as screenshot ( https://play.google.com/store/apps/details?id=com.geeksoft.screenshot&hl=en ) as well as pay for screenshot capture apps that do not require root ( https://play.google.com/store/apps/details?id=com.edwardkim.android.screenshotitfullnoroot&hl=en )

Having mentioned these, I am not endorsing any apps one over the other… if you find a favorite one that shows/shares logs or screenshots, I say go for it!

Filed under: mobifx, mobile, Planet, QA, QMO Tagged: mobifx, mobile, Planet, QA, QMO

May 11, 2012 07:23 PM

May 10, 2012 07:58 AM

May 10, 2012 07:57 AM

For those that aren't already aware, many Mozillians gathered last week in Toronto to Maximise Synergy. Seeing as there have been updates for the UX team and the Firefox/Mobile UI team, I think it'd be worth having a similar update for mobile platform. Some fantastic work is going on in this area, and people deserve kudos :)

• Kartikaya Gupta (aka kats) continues to do sterling work, fixing an inhuman amount of bugs. Most prominently, kats has been working on our display-port 'strategies', code that allows us to make the most of our rendering time and, thus, reduce checkerboarding. He's also been working on our checkerboard measurement, augmenting and refining our tests and test-method to make sure we're always pushing ourselves. This, alongside much general bug-fixing work.
• Benoit Girard (aka BenWa) is part of the gfx team, all of whom have been helping us out for the past few months, getting our performance back to a competetive level. Benoit's tiled rendering patches finally landed, which make a huge difference to performance. Benoit has also been working on some useful remote profiling tools, which he blogs about here.
• James Willcox (aka snorp) continues to battle Flash to get us the best Flash experience in an Android browser (ironic, right?) snorp's work to get more accurate positioning of Flash elements landed, along with his work to replace elements with a snapshot during page movement on Froyo/Gingerbread, completing the experience.
• Brad Lassey (aka blassey) managed to get enough time to do some coding alongside his usual cat-herding responsibilities, and got us a low-res page cache. This means that in the rare situation that our rendering can't keep up, instead of showing checkerboard, we show a low-resolution rendering of the page. It's possible that this content can go stale, but we find it provides a much better experience than showing either a blank colour or checkerboard. This works much better than any of us expected it to, and for me at least, was the turning point after which I find our browser much easier to recommend.
• And me? I managed to get my retained tiles patch landed. Currently, we render the page into system-memory tiles, which we then upload to the GPU. My patch keeps a hold of the GPU tiles and metrics for a while after they're invalidated. Again, when our renderer can't keep up, it renders these old tiles into the space instead of rendering nothing. This mostly helps quick changes of direction and zooming out after zooming in. I also spent some time fixing up the low-res cache work, then fixing up my fix-ups, as is my custom :) Hopefully, preliminary fixed-position layer support will also land soon.

Much other work also occured, and sorry for missing anyone out that I surely did. It's worth mentioning that the gfx team have been a huge help and have been working extra-hard for months now, helping us get to where we are today (and hopefully beyond!) I had a great (and hard) time during my stay and am very much looking forward to our upcoming release :)

May 02, 2012 02:50 PM

It's been a few months now since we merged the mobile and desktop Firefox user-experience teams into one supercharged all-platform Firefox design juggernaut (in the good sense). In that time, we've been hard at work digging into the next set of features and improvements, as well as pursuing one of our major goals for the year: getting Firefox to feel more like one product — more Firefoxy — across all our platforms, desktop to tablet to phone.

I presented an overview of what we're working on at the Firefox Toronto Workweek last week. Here are the slides (and a direct link, just in case). I had a fair bit to say about them, so I'll be posting a video of the talk soon, but the mockups and wireframes in the slides are too awesome to wait. The team will be posting about each of these projects, individually, in more depth.

Ux overview fxworkweek_april2012

View more presentations from Madhava Enros

This presentation makes reference to the Kilimanjaro project, a set of short-term priorities around integrating the browser and ecosystem projects (identity, apps, marketplace) that Mozilla is working on right now. You can learn about it on the Kilimanjaro wiki page.

Many thanks to the team (see slide 2!) for all their hard work.

May 01, 2012 05:29 PM

This past week the Firefox front-end team had a work week in Toronto, and had the chance to give a lightning talk about the new Fennec Native UI. This talk is geared towards developers who are already familiar with working on desktop Firefox, but it will give anyone a quick overview of how our mobile front-end is built. I also made the slides available, since they include some links.

Update: Here’s a direct link to the video.

April 29, 2012 04:28 PM

The Mobile team spent last week in not-so-sunny Toronto, pushing Firefox for Android closer to beta-level release criteria. We are getting very close. There is a lot of amazing work landing, especially in graphics. The Graphics team is working with Mobile to integrate GL support into the Gecko rendering system. It’s taken some time, but the results are really starting to look good in Nightly builds.

Mobile wasn’t the only team meeting in Toronto. The Firefox team also got together, and one of main features of the week was HACKING. Pure, seat-of-the-pants hacking. A few of the Mobile team were able to take part in the hack sessions too:

• Lucas created a nice prototype of the new Reader Mode in Firefox Mobile. He integrated some of the readability code, created a special viewer and a way to manage reading lists.
• Margaret has a work-in-progress of HTML5 context menu support working.
• Margaret also updated a patch to add support for the site identity UI.
• Sriram started work to support text selection in web page content.
• Jan Odvarko (DevTools) created a prototype of a remote network monitor tool working with Firefox on Android. With the new remote JS debugger, that’s two new remote development tools in the pipeline.

April 29, 2012 04:37 AM

One of the things I've been working on for the last while is the integration between the Fennec front-end and the core graphics APIs. One of the main problems in this kind of work is having to deal with multiple different coordinate systems and units of measurement. For coordinate systems, we have:

• the page, which is the area determined by the content being rendered
• the screen, which is determined by the physical hardware the user has
• the viewport, which is the part of the page the user sees on the screen
• the displayport, which is the area Gecko is actually rendering to graphics buffers
• the CSS viewport, which is the base relative to which some content dimensions are calculated

For units of measurements, we have:

• device pixels, whose size is fixed by the hardware
• CSS pixels, which can grow or shrink relative to device pixels depending on the zoom
• app units, which are what Gecko uses internally for layout calculations, and are 1/60 of a CSS pixel

With all these different frames of reference and units of measurement it sometimes gets pretty hard to keep it all straight. As a tool to help me visualize this, I wrote a simple SVG file that lets me quickly simulate certain behaviours. The SVG file shows a device overlaid on top of a screenshot of CNN.com, and allows you to drag around the device so that you can see how the viewport and displayport might change. It also allows you to simulate zooming in and out (using the '-' and '+' keys) and asynchronous panning (use 'p' to pin/unpin the displayport).

You can find the SVG file here (warning: it loads a ~1.5MB CNN screenshot). Feel free to play around with it, or hack it up to suit your own needs!

April 27, 2012 03:32 AM

I went to Évora this week to give a talk about Mozilla and our mobile projects (Firefox Mobile, B2G, Open Web Apps, Identify, etc) at an event organized by the students’ union of the local university. Here’s my talk’s deck of slides (in Portuguese)—not very useful as it has very little content but it does contain a few useful links.

My main conclusion from this event is that we, Mozillians, should probably dedicate some more time spreading the word about our mission and projects to Uni students, especially in CS. There seems to be little awareness of why we’re different, why our mission matters, and what we’re working on right now.

From my experience, universities are usually a great source of potential long-term open source contributors. Getting students excited about our projects is likely to help us have a constant flow of new contributors in our community.

Big thanks to the event organizers for inviting me and for the hospitality! It was great to see Joaquim Rocha (Igalia) again and also meet interesting people like Thomas Perl (gPodder) and Steven Goldfarb (CERN). It was a quick yet pleasant visit to Portugal.

April 19, 2012 11:12 AM

ctalbert just posted a new dashboard for s1/s2 tests:  http://mrcote.info/phonedash/#/

What is s1/s2 testing?  It’s basically a startup testing for trying to measure throbber start/stop, and drawing end times.  Manual run instructions can be found here : https://etherpad.mozilla.org/fennec-perf-ts-take2  ( Side Note : I need to clean up the wiki here : https://wiki.mozilla.org/Mobile/Performance/S1S2-Tests)

The code for the test automation can be found here: https://github.com/ctalbert/xbrowserstartup

Filed under: mobifx, mobile, Planet, QA, QMO

April 18, 2012 06:04 PM

See this link : https://bugzilla.mozilla.org/show_bug.cgi?id=731333#c7

Blassey made a tool to specifically OOM fennec.

Filed under: mobifx, mobile, Planet, QA, QMO

April 17, 2012 05:31 PM

I'm sure quite a few you have seen the "wat" talk exposing some funny behaviors of Ruby and JavaScript. Working in the industrial/enterprise/boring Java language most of the time for Native Fennec's development, we've been missing out on such interesting moments. Nevertheless, I present you this gem, from bug 745384:

• (null instanceof <anything>)  = false

  This is guaranteed by the language spec:

   "At run time, the result of the instanceof operator is true if the value of the RelationalExpression is not null and the reference could be cast (§15.16) to the ReferenceType without raising a ClassCastException. Otherwise the result is false."

• IsInstaceOf(NULL, <anything>) = JNI_TRUE

  This too is guaranteed by the language spec:

   "Returns JNI_TRUE if obj can be cast to clazz; otherwise, returns JNI_FALSE. A NULL object can be cast to any class."

I don't know what the people at Sun were thinking when they designed it this way, but right now I'm all:


For those wondering, these are the relevant Java bugs:

• http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4074494
• http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4081023

Note the "Closed, Not a Defect, Fixed in spec." It's not a bug, it's a feature, :-)

April 14, 2012 06:11 PM

For those that don’t look at Socorro too often, there’s a new icon that shows you if there’s a startup crash.

The indicator is circled in red.

Basically if a crash signature has an uptime of less than 1 minute for 50 % or more of it’s crashes, then it will show this new indicator.  Here’s a link to the crashes for 14.0a1 so you can see for yourself :

https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/14.0a1/7

Note: the strike thru bug numbers, indicate closed bugs, dev has been working hard in trying to close out the top crashing bugs.  The numbers are cumulative of all build versions of 14.0a1 within the past week that have crashed with a certain crash signature.  So basically… please please please update and update often before testing!

Filed under: mobifx, mobile, Planet, QA, QMO Tagged: mobifx, mobile, Planet, QA, QMO

April 06, 2012 08:25 PM

There are other crash reports other than Socorro that are being generated.

Thanks to kairo and chofmann; there are other ways to look at the data that is provided by Socorro.

Kairo has made an adjustment asked by the crashkill team to his original script that I had asked for earlier:

https://crash-analysis.mozilla.com/rkaiser/2012-04-01/2012-04-01.fennecandroid.nightly.devices.html

You’ll notice in the link, that it shows the crashes that a device has, with the number of crashes to the right.  If you continue to scroll, you will notice the devices that a crash has, with the number of crashes to the right.

This helps out in determining faster whether a crash is only happening on a certain device/chipset as well as which devices to try to reproduce the crashes with.

For more of kairo’s crash reports see : https://crash-analysis.mozilla.com/rkaiser/

Chofmann has his own sets of reports.  For example :

https://crash-analysis.mozilla.com/chofmann/20120404/mobile-central-crash-trend.csv

This shows the cumulative crashes of a version per day, so you can understand where the numbers are coming from in Socorro.

For more of chofmann’s reports see :

https://crash-analysis.mozilla.com/chofmann/

Filed under: mobifx, mobile, Planet, QA, QMO, Uncategorized Tagged: mobifx, mobile, Planet, QA, QMO

April 05, 2012 04:01 PM

I’ve been messing around with Android-based code for a few months now while hacking on Native Firefox for Android. I noticed that the performance tips for ListViews are a bit scattered in different sources. This post is an attempt to summarize the ones I found most useful.

I’m assuming you’re already familiar with ListViews and understand the framework around AdapterViews. I’ve added some Android source code pointers for the curious readers willing to understand things a bit deeper.

How it works. ListView is designed for scalability and performance. In practice, this essentially means:

1. It tries to do as few view inflations as possible.
2. It only paints and lays out children that are (or are about to become) visible on screen^code.

The reason for 1 is simple: layout inflations are expensive operations^code. Although layout files are compiled into binary form for more efficient parsing^code, inflations still involve going through a tree of special XML blocks^code and instantiating all respective views. ListView solves this problem by recycling^code non-visible views—called “ScrapViews” in Android’s source code—as you pan around. This means that developers can simply update the contents of recycled views^code instead of inflating the layout of every single row—more on that later.

In order to implement 2, ListView uses the view recycler to keep adding recycled views below or above the current viewport and moving active views to a recyclable pool as they move off-screen^code while scrolling. This way ListView only needs to keep enough views in memory to fill its allocated space in the layout and some additional recyclable views—even when your adapter has hundreds of items. It will fill the space with rows in different ways—from top, from bottom, etc—depending on how the viewport changed^code. The image below visually summarizes what happens when you pan a ListView down.

With this framework in mind, let’s move on to the tips. As you’ve seen above, ListView dynamically inflates and recycles tons of views when scrolling so it’s key to make your adapter’s getView() as lightweight as possible. All tips resolve around making getView() faster in one way or another.

View recycling. Every time ListView needs to show a new row on screen, it will call the getView() method from its adapter. As you know, getView() takes three arguments arguments: the row position, a convertView, and the parent ViewGroup.

The convertView argument is essentially a “ScrapView” as described earlier. It will have a non-null value when ListView is asking you recycle the row layout. So, when convertView is not null, you should simply update its contents instead of inflating a new row layout. The getView() code in your adapter would look a bit like:

public View getView(int position, View convertView, ViewGroup parent) {
    if (convertView == null) {
        convertView = mInflater.inflate(R.layout.your_layout, null);
    }

    TextView text = (TextView) convertView.findViewById(R.id.text);
    text.setText("Position " + position);

    return convertView;
}

View Holder pattern. Finding an inner view inside an inflated layout is among the most common operations in Android. This is usually done through a View method called findViewById(). This method will recursively go through the view tree looking for a child with a given ID^code. Using findViewById() on static UI layouts is totally fine but, as you’ve seen, ListView calls the adapter’s getView() very frequently when scrolling. findViewById() might perceivably hit scrolling performance in ListViews—especially if your row layout is non-trivial.

The View Holder pattern is about reducing the number of findViewById() calls in the adapter’s getView(). In practice, the View Holder is a lightweight inner class that holds direct references to all inner views from a row. You store it as a tag in the row’s view after inflating it. This way you’ll only have to use findViewById() when you first create the layout. Here’s the previous code sample with View Holder pattern applied:

public View getView(int position, View convertView, ViewGroup parent) {
    ViewHolder holder;

    if (convertView == null) {
        convertView = mInflater.inflate(R.layout.your_layout, null);

        holder = new ViewHolder();
        holder.text = (TextView) convertView.findViewById(R.id.text);

        convertView.setTag(holder);
    } else {
        holder = convertView.getTag();
    }

    holder.text.setText("Position " + position);

    return convertView;
}

private static class ViewHolder {
    public TextView text;
}

Async loading. Very often Android apps show richer content in each ListView row such as images. Using drawable resources in your adapter’s getView() is usually fine as Android caches those internally^code. But you might want to show more dynamic content—coming from local disk or internet—such as thumbnails, profile pictures, etc. In that case, you probably don’t want to load them directly in your adapter’s getView() because, well, you should never ever block UI thread with IO. Doing so means that scrolling your ListView would look anything but smooth.

What you want to do is running all per-row IO or any heavy CPU-bound routine asynchronously in a separate thread. The trick here is to do that and still comply with ListView‘s recycling behaviour. For instance, if you run an AsyncTask to load a profile picture in the adapter’s getView(), the view you’re loading the image for might be recycled for another position before the AsyncTask finishes. So, you need a mechanism to know if the view hasn’t been recycled once you’re done with the async operation.

One simple way to achieve this is to attach some piece of information to the view that identifies which row is associated with it. Then you can check if the target row for the view is still the same when the async operation finishes. There are many ways of achieving this. Here is just a simplistic sketch of one way you could do it:

public View getView(int position, View convertView,
        ViewGroup parent) {
    ViewHolder holder;

    ...

    holder.position = position;

    new ThumbnailTask(position, holder)
            .executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, null);

    return convertView;
}

private static class ThumbnailTask extends AsyncTask {
    private int mPosition;
    private ViewHolder mHolder;

    public ThumbnailTask(int position, ViewHolder holder) {
        mPosition = position;
        mHolder = holder;
    }

    @Override
    protected Cursor doInBackground(Void... arg0) {
        // Download bitmap here
    }

    @Override
    protected void onPostExecute(Bitmap bitmap) {
        if (mHolder.position == mPosition) {
            mHolder.thumbnail.setImageBitmap(bitmap);
        }
    }
}

private static class ViewHolder {
    public ImageView thumbnail;
    public int position;
}

Interaction awareness. Asynchronously loading heavier assets for each row is an important step to towards a performant ListView. But if you blindly start an asynchronous operation on every getView() call while scrolling, you’d be wasting a lot of resources as most of the results would be discarded due to rows being recycled very often.

We need to add interaction awareness to your ListView adapter so that it doesn’t trigger any asynchronous operation per row after, say, a fling gesture on the ListView—which means that the scrolling is so fast that it doesn’t make sense to even start any asynchronous operation. Once scrolling stops, or is about to stop, is when you want to start actually showing the heavy content for each row.

I won’t post a code sample for this—as it involves too much code to post here—but the classic Shelves app by Romain Guy has a pretty good example. It basically triggers the async book cover loading once the GridView stops scrolling among other things. You can also balance interaction awareness with an in-memory cache so that you show cached content even while scrolling. You got the idea.

That’s all! I strongly recommend watching Romain Guy and Adam Powell’s talk about ListView as it covers a lot of the stuff I wrote about here. There’s nothing new about the tips in this post but I thought it would be useful to document them all in one place. Hopefully, it will be a useful reference for hackers getting started on Android development.

April 05, 2012 11:24 AM

Do you suffer from bugmail overload? Do you often declare bugmail bankruptcy? Have a set of bugmail filters so complex they break every time you change them? If so, this post might be for you!

A few months ago, I too was a chronic sufferer of bugmail overload. The best approaches to handling bugmail I could glean from my fellow Mozillians revolved around using Gmail, tuning email preferences in Bugzilla, and filtering heavily. The problem, however, is that I like getting bugmail. I like being able to watch a component and stay on top of what's going on. It's not so much a case of getting too much bugmail, as it is a case of not being able to process it fast enough.

So I decided to write a bugmail dashboard that would solve this problem. In a nutshell, it scrapes incoming bugmail and extracts all the relevant pieces of information, stuffing them into a MySQL database. A web-based front-end then displays that information in a very compact representation that allows me to view large volumes of bugmail efficiently. Here is a screenshot of what it looks like. And here is a random subset of features:

• Presents information from multiple bugs on the screen simultaneously, so you don't have to wade through different emails to read everything.
• Prioritizes bugs into columns; the leftmost column is most important and rightmost column is least important.
• Marking stuff is as viewed is done on a per-bug basis (using XMLHttpRequest so it's nice and responsive).
• Marking one bug as viewed moves the next bug up so you don't even have to move your mouse, kinda like Firefox's tab close buttons!
• Interface is very mobile-friendly so you can easily process bugmail on your phone during idle moments.

I've been using and improving this dashboard for a couple of months now, and it's getting stable enough that others may want to try it out. I still consider it "alpha" quality though, largely because it's non-trivial to set up and get going. If you're interested in trying it out, grab the source from github.com/staktrace/bugmash and take a look at the README.html file for instructions on how to set it up.

If you have any feedback, please send me email and/or file bugs in github and/or submit pull requests!

April 01, 2012 08:13 AM

For the past few months, I’ve been spending most of my time helping the mobile team with the Fennec NativeUI rewrite, and a few weeks ago I officially became a member of the mobile front-end team. Although working on a native Android app has been painful different, I’ve found my desktop browser knowledge to be really useful, especially when working on Fennec features that I also helped make on desktop Firefox. I’m hoping that this will encourage the desktop and mobile teams to work together more closely, since we’re really just all part of a bigger team trying to make an awesome Firefox experience across all of your devices.

I’ve neglected to blog about the mobile work I’ve been doing these past few months, but I’ll use the excuse that I was too busy writing code instead! Among other things, I’ve been working on click-to-play plugins, doorhanger notifications, site settings, bookmarks, and our form assistant UI. Grab a Nightly build to see our most recent changes, or check out Aurora for a more stable experience.

March 29, 2012 05:01 PM

As you probably know by now, the DevTools team got together here in London last week. I attended their work week with the specific mission of getting remote debugging to work on Firefox Mobile (a.k.a Fennec).

The result? I wrote a couple of patches that allow you to debug JavaScript code from web pages running on Firefox Mobile. You can add breakpoints, step through your JS code, track the call stack and variable values from the experimental script debugger in Firefox’s Nightly build on desktop.

The script debugger uses the remote debugging protocol to send commands to Fennec via network. You have to connect your Android device to your computer via USB and map a localhost port using the follow adb command:

adb forward tcp:6000 tcp:6000


This will map port 6000 on your computer with the same TCP port on your mobile device. There’s no UI in the script debugger to connect to a remote Firefox instance yet but the DevTools team already have a patch series adding that. My patches simply implement the necessary actors that expose all browser tabs to the script debugger.

Remote debugging is especially important for mobile web developers. They need a way to easily tweak pages on the mobile device and see the results instantly. Right now, the remote debugging protocol only allows you to debug JavaScript code but  the long-term goal is to allow web developers to do much more: injecting code, inspecting DOM nodes, tweaking CSS rules, etc.

As you can see, there’s a lot of exciting work in progress here and many patches about to land in our repositories very soon. Stay tuned!

March 28, 2012 03:43 PM

Similar to proximity, Many devices also have light sensors embedded in them. To expose this to web content we should just use DOM Events similar to that of Device Motion and Device Orientation. A developer simply has to register an event listener:


window.addEventListener("devicelight", callback, true);


The callback’s parameters include:

value – the current ambient light level in SI lux units


function callback(a) {
var d = document.getElementById("d");
d.innerHTML = "<p> Current Value " + a.value
}


Like Device Proximity, the sensor will be turned on when the first listener is added. And, of course, the sensor will be turned off when the last event listener is removed.

This work is being tracked in bugzilla bug 738465. Sample webpage: http://dl.dropbox.com/u/8727858/mozilla/light/light.html

I hope to get this in for Firefox 14 or 15, and of course, B2G.

March 26, 2012 06:10 PM

The State of the Mobile Web

It is unfortunate and largely concerning that the mobile web is currently fractured. There are far too many mobile web sites out there targeting either -webkit (to achieve engine-specific functionality), and or deprecated -moz prefix extensions (a lot of which these properties have been long past their draft CSS specification). Robert Nyman’s recent blog post mentions some of the number of problems with the state of the mobile web, who to blame for the fracturing, methods to evangelize solutions and what to do moving forward. There are plenty of interesting and relevant posts out there as of recent with varied proposals and potential solutions. This posting is focused on some of the testing activities one may consider when stumbling upon a site in Firefox for Android that does not function properly or look correct in comparison to other browsers on the Android platform and how one can get started today in making the mobile web better.

Gecko Testing in Firefox for Android

The goal is rather straightforward: to collect, extrapolate and coalesce all the relevant data provided from testing to report on the issues found and act using the lever of collected data to improve website compatibility for Firefox and open standards-based development. Let’s take a look at a few activities that one can perform to help identify and act on issues found.

When viewing a website one can begin by invoking the Android Debug Bridge’s Logcat utility or DDMS  to scan for Gecko Error Console messages. The Gecko Error Console engine is rather useful for logging relevant and valuable data which in turn can be helpful in initial investigation into pinpoints and areas of failure.

During site-load or on an any site interaction Gecko (i.e, tagged GeckoConsole) will log JavaScript Warnings as Error level (verbosity) messages . These warnings provide reason to infer code issues that reflect upon the quality and functionality of the site in Gecko and in Firefox for Android. Example output:

E/GeckoConsole( 5261): [JavaScript Warning: "Unknown property '-moz-background-size'. Declaration dropped." {file: "example.css" line: 8}]

E/GeckoConsole( 5261): [JavaScript Warning: "Unknown property '-moz-border-radius'. Declaration dropped." {file: "example.css" line: 8}]

E/GeckoConsole( 5261): [JavaScript Warning: "Unknown property '-moz-box-shadow'. Declaration dropped." {file: "example.css" line: 8}]

In the example output above, the declarations were dropped and JavaScript Warnings are shown detailing the incompatibility. Ultimately this could yield poor experiences through use or through view of any particular website. Oddities can appear such as: layout issues, element overlap, missing content, and in essence areas of the page not shown correctly – all of which could affect the overall experience.

Test by impersonating other browser vendor’s user agents

Install and Run Phony. Common amongst the vastness of the web is an unfortunate practice of coding scripts and libraries that magnify internal details of a users Internet browser specifically targeting the user agent in order to determine the web browser a visitor is using, and to serve browser-appropriate content to the visitor. It is a practice sometimes utilized to circumvent incompatibilities between browsers in areas such as the interpretation of HTML, Cascading Style Sheets (CSS) and the Document Object Model (DOM). To confirm that user agent sniffing is in use, one can install Phony for Firefox on Android to alter the default user agent and modify it to a different preset, such as the default stock Android browser (WebKit) or Safari for iOS (WebKit). If the results of the user agent modification are vastly different in terms of the site fetched and displayed in the browser, then we know that this practice is unfortunately in use.

One can also scan the host’s JavaScript files (Firebug or Firefox’s Web Console) to dive into site elements, resources, and scripts to reveal the content returned. By investigating and analyzing through these contextual based utilities one can scope out and reference information about browser compatibility and W3C Recommendation compliance of page elements, among many other types of valuable information.

Alongside, can also determine if site-redirection is happening too as a result of user agent sniffing

The cURL command-utility is a simple way to to quickly see if redirection as a result of a provided user-agent is occurring. Example below with a target site Engadget and the Mozilla Firefox for Android’s current user agent:

curl -ILA "Mozilla/5.0 (Android; Mobile; rv:14.0) Gecko/14.0 Firefox/14.0a1" engadget.com

Running the above command returns:

HTTP/1.1 301 Moved Permanently
Date: Mon, 26 Mar 2012 14:37:13 GMT
Server: ArtBlast/3.5.5
MIME-Version: 1.0
Expires: Mon, 26 Mar 2012 15:07:13 GMT
Content-length: 90
Content-type: text/html
Location: http://www.engadget.com/

HTTP/1.1 200 OK
Date: Mon, 26 Mar 2012 14:37:13 GMT
Server: Apache/2.2
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Set-Cookie: ipaduser=deleted; expires=Sun, 27-Mar-2011 14:37:12 GMT; path=/; domain=.engadget.com
Set-Cookie: GEO-66_207_208_98=can%3A%3Atoronto%3A%3A043.751%3A%3A-079.443%3A%3Abroadband%3A%3Aon; expires=Mon, 26-Mar-2012 15:37:13 GMT; path=/
Content-Type: text/html

And with a recent Apple iPhone user-agent:

curl -ILA "Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A405" engadget.com

Returns:

HTTP/1.1 301 Moved Permanently
Date: Mon, 26 Mar 2012 14:38:05 GMT
Server: ArtBlast/3.5.5
MIME-Version: 1.0
Expires: Mon, 26 Mar 2012 15:08:05 GMT
Content-length: 90
Content-type: text/html
Location: http://www.engadget.com/

HTTP/1.1 302 Found
Date: Mon, 26 Mar 2012 14:38:05 GMT
Server: Apache/2.2
Location: http://m.engadget.com/default/home.do?category=classic&icid=eng_classic
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 200 OK
Date: Mon, 26 Mar 2012 14:38:06 GMT
Server: Apache
Content-Length: 43740
Content-Type: text/html;charset=UTF-8

In the examples above we request the HTTP-header only with a provided user-agent and re-perform the request if a server reports a 3XX response. With the same examples above, an entirely different site is retuned for each user-agent. When viewed in a browser the user will get an entirely different site depending on which browser they are using. Often the case one will either get a desktop version or basic HTML (unfortunately, occasionally even WAP).

A judgement call can be made based on some analysis to determine wherein the core issues lie based on some simple analysis. Jason Smith has recently created a blog post explaining the process of how one can dig deeper into subjective website analysis to provide and pinpoint exact engine-related issues.

How You Can Act on the Issues You’ve Come Across

File Bugs on Bugzilla

Evangelism

Ten years ago, Netscape and Mozilla together put together a massive technical evangelism program to persuade an IE-focussed web to consider Gecko and other rendering engines. Today, we need the same thing for a Webkit-focused mobile web.

Ultimately, one must work with web developers to help them understand why building web pages using open standards and open tools is important, how they can achieve cross-browser compatibility using standard methods and libraries, and how they can help tell that story to others who might be interested as well. Mobile Evangelism efforts at Mozilla have recently started rolling and we could use your help through site testing (identifying problems we are looking for), integrating user testing into our products, getting the word out through PR approaches, developer engagement, creating tools, and working with other vendors to collaborate on common issue.

 Related Links

March 26, 2012 03:34 PM

It's been way too long since I last blogged, so here's something to try and get into the mood again. I have a few other things I'd like to write about, but work here at Mozilla is probably the most pressing one at the moment, so the others will have to wait.

Those who have been following Nightly, and/or who attended our talk at FOSDEM would be aware that we're currently rewriting the Android version of Firefox Mobile. The major part of this change is that we're now a 'native' Android app, rather than a XUL app. Consequently, we fit in and behave much better than the older version of Firefox Mobile, and we get a few perks too; namely start-up performance.

Alongside this new version of Firefox Mobile, we've also taken the opportunity to overhaul the platform side of things. Where as the old version was multi-process, we've now switched to a multi-threaded application model, with the input, content processing/rendering and UI rendering all taking separate threads. Just recently, we switched from a Java-based view compositor to a native-code off-main-thread-compositor (or OMTC, for short). While previously we drew the entire page into a buffer (with extra bits around the edges) and composited that, we now directly composite the layers that make up the page.

This gives us the speed and ease of using a single process (to some extent), but with the power afforded to us by an asynchronous rendering process. Most of what I said previously about shadow layers still applies, just replace 'process' with 'thread'. Most of the problems still apply too, but the graphics team has put in some phenomenal work in fixing a lot of it.

So we're now working our figurative nuts off fixing all the bugs that have cropped up, but I do believe we're on the road to success. This rendering model gives us the power to retain a lot more content than before, and any saved drawing tends to translate into massive benefits on mobile - we appear to be mostly memory-bandwidth limited, so every little helps. What this translates to for users is smooth, 60fps updates, excellent interactive performance, excellent web standards support and a polished, 'native' feeling application. You can sample some of this work by downloading a Nightly build, it's *almost* at the point of being a daily driver (not quite, but almost).

Maybe you want to help? Running a nightly build and providing feedback (either via the built-in methods, or by filing bugs) is a great way to start, and all the mobile developers hang out on IRC too, in #mobile. We've also just opened a new office in London, and I do believe we're hiring, so if you think you'd like to get in on some of this, do contact us!

Update: The built-in method for feedback is far less obvious than I thought... You can access it via the 'About' page, (accessible via the settings menu), then following the links 'Support', 'Ask a Question', and finally 'Give us feedback'. I think we should make this better, so I've filed a bug.

March 23, 2012 06:40 PM

Many devices have proximity sensors embedded in them.  To expose this to web content we should just use DOM Events similar to that of Device Motion and Device Orientation.  A developer simply has to register an event listener:


window.addEventListener("deviceproximity", callback, true);


The callback’s parameters include:

value – the current distance to the proximity sensor in cm.
min – the minimum value that the sensor and report.  Usually zero.
max – the maximum value that the sensor can report.


function callback(a) {
var d = document.getElementById("d");
d.innerHTML = "<p> Current Value " + a.value +  "<p> Max = " + a.max +  "<p> Min = " + a.min
}


Like Device Motion and Device Orientation, the sensor will be turned on when the first listener is added.  And, of course, the sensor will be turned off when the last event listener is removed.

This work is being tracked in bugzilla bug 738131.  Sample webpage:  http://dl.dropbox.com/u/8727858/mozilla/proximity/pro.html

I hope to get this in for Firefox 14 or 15, and of course, B2G.

March 22, 2012 04:23 PM

Something that's bitten me more than once during Fennec development is making some changes to browser.js, going through the super-long build cycle, running my code, only to find out there was a syntax error of some sort in my change, which causes Fennec to not start up correctly. When this happens, it is a huge waste of time, and quite frustrating to boot.

Although I've filed bug 715242 to track this issue and fix it properly as part of the build process, I've also thrown together a quick way to do this in my local builds.

First, build the js engine as a standalone binary for your machine. If you have a host build of mozilla-central you might already have a working copy in your <mozilla-central-objdir>/js/src directory. If not, do the following (adapted from the SpiderMonkey build instructions):

mkdir -p ~/tmp/js-build
pushd ~/tmp/js-build
<mozilla-central-srcdir>/js/src/configure
make
popd

This will build a "js" binary that you can run with the -c flag to syntax-check JS files. Put this on your $PATH somewhere. Unfortunately, some of the .js files you'll want to syntax check (such as browser.js) are also preprocessed. Figuring out where in the build to find the post-processed versions of these files was too much work, so I went with the simple and easy approach:

grep -v "^#" $1 > ~/tmp/check-this.js
js -c ~/tmp/check-this.js

If you throw the above into a script and run it with a .js file as an argument, it will exit with zero on success and nonzero on failure, so you can conditionally run the rest of your build. I do this in my build scripts, which you can see in my github repo at https://github.com/staktrace/moz-scripts/ - look at the jscheck and build-android.sh files in particular.

March 22, 2012 04:42 AM

So it's been about five and a half months since I started working at Mozilla. Kind of ironic that I haven't yet blogged about it, considering they encourage their employees to blog early and often, and being able to blog about work stuff was definitely one of the things that attracted me to Mozilla in the first place.

Officially I'm on the mobile platform team, working on the parts of the code that deal with the mobile browsers (i.e. Firefox for Android, aka Fennec) interaction with the core Gecko rendering engine. However, since we've been focused on a rewrite of the entire Fennec front-end, everybody on the mobile team has been working on whatever needs to be done, and the lines are pretty blurry anyway. Currently I'm working on the pan/zoom behaviour of Fennec, ensuring the user can navigate around the page smoothly and efficiently, encountering as little "checkerboarding" as possible.

Working at Mozilla so far has been pretty interesting. In the world of software, it's almost the polar opposite of RIM (particularly RIM as it was when I left). Working on open source software in an open development process is obviously a large part of it. All our code is publicly available, and a lot of the discussion that goes on happens on Bugzilla and IRC, where anybody can see and participate.

But even more important, and quite surprising to me, is the emphasis on community. Mozilla has a huge focus on building a community around the web - to the extent that every office has a dedicated community space where they host events. For example, during the last week at the Toronto office, we had a "Girls learning code" event where 11-14 year old girls could come and learn about the web and technology in general. This is an aspect of Mozilla that I think a lot of people aren't really aware of (I was only vaguely aware of it before I started here), but it is a core part of the company and mission.

I don't want to ramble on right now, but I plan to blog on Mozilla-specific things, both technical and non-technical, in the future. I suspect some of those posts will not be of general interest, so I'll keep them off the main blog, but you can get at them by going to https://staktrace.com/spout/?tag=mozilla. The RSS feed will likewise be at https://staktrace.com/spout/getrss.php?tag=mozilla. Feel free to subscribe to that if you want to see Mozilla-specific blog content.

March 18, 2012 12:17 AM

There’s nothing special about today’s date but I feel it’s a good time to write a bit about my experience at Mozilla so far.

First days. Joining Mozilla was, at least in the first few weeks, a rather scary experience. Mostly because it was an unknown territory—both socially and technically—and I had a lot of catching up to do. The amount of information you have to assimilate in order to understand how things are done is a bit overwhelming. But here I am, I survived! And still catching up.

Remote. One of the main concerns I had when I joined Mozilla was the working-from-home part. I’ve done it before but not for so long. It turned out to be a good experience and enjoyed it in many ways. But I still missed meeting workmates in person and having a more clearly separate environment for work. So, I’m glad that the awesome London office is now open!

Challenges. I  joined Mozilla in a very interesting moment. The company is growing a lot (we’re hiring) and has gone and is still going through many changes: new release pace, native UI for Firefox on Android, Boot to Gecko, Identity, Open Web Apps, and much more. New focus, projects, and products but the mission is still the same.

Hacker-friendliness. Mozilla is a very friendly environment for hackers: meritocratic, pragmatic, and virtually bullshit-free. Feels good. You’re pretty much free to decide what to do next with very simple guidance as to what has higher priority at point in the development process.

Passion. Mozilla’s mission is taken very seriously. You see that reflected in every small and big decision inside the organization. Being a non-profit organization with such a worthy mission is very liberating because you can express your passion with no excuses. Mozillians are very passionate people.

Quick stats. I joined Mozilla 238 days ago. Since then, as part of my work at the company, I pushed 204 changesets, changed ~7,395 lines of code, fixed 106 bugs, gave 2 talks, travelled to 4 countries, and met a huge number of smart people.

March 13, 2012 11:59 AM

To me, QA is about reporting what the current behavior of the application is,
for better or worse.  This means reporting what works and what does not work.
Overall testing means to check every button to make sure that the application
behaves as expected.  There are a lot of testing to do where bugs for a feature
can be found in various areas such as UI, Data, Functionality, Integration and
Environment. When you want to find crashers and critical bugs… that’s when you
have to worry about timing and sequence of events. [Edit: this also means to ensure what has worked stays working, what's fixed is fixed and the fix involves everything around that might end up leading to the same bug.]

Testing does not require computer science knowledge; being a good tester doesn’t
require having computer science knowledge. What it does require is having a
scientific/methological mindset.  What I mean by that is understanding what and
how to keep certain variables/conditions constant while testing one by one each
variable/condition thoroughly. Some variables/conditions could be lumped in the
same tests, and to understand that requires a deeper understanding. Having the
same vocabulary as the developers helps with that and having a computer science
background of being able to read code and understand the developers/code gives a
huge advantage in being a tester. You do not need a degree in order to have a
computer science background, but it helps to prove that you do have one. It also
helps to have some experience in trying to program.  Why?  Because it helps you
understand where you might encounter bugs as a coder and understand where
certain weak points may be in code.

Side note: one of the best testers I know doesn’t have a computer science
degree, but had learned how to program on the side by himself.  He also has over
12 years of experience working on the same code base that he does QA on. One of
the things I noticed that a good QA person does is he does not assume; based on
what is said or done, he reports what occurs in the application by testing and
verifying the results.

When are the most critical paths that you have to worry about?  When you create,
add/insert, delete, destroy something.  Something can be anything, ie, an
object, a window, an array, a pointer, or a mutex.  This is something I noticed
back in college when I was trying to create various sort options such as
insertion sort, bubble sort, etc.  Classic Comp Sci programming of various
algorithms.  The biggest thing I noticed was when I made a mistake on how to
insert or delete a pointer… it could cause the program to blow up.  Worst was
when you were dealing with recursion and the operating system doesn’t have
memory management. [Pascal programming on Mac OS 8.6]  Nightmare.  That was in
high school. heh.

For example some of the testing that devs may miss is starting from a new
account.  Starting from a blank new slate and then running the application. You
may run into initialization issues at that point.

Simple cases may work, finding the harder bug requires a better understanding of
behind the actions and when things occur and how.

An example would be sync running and looking at the bookmarks section within
Native Fennec. Two different processes running, one adding items to the
database, one viewing the database. This is where 2 applications are looking at
the same file.  (Just a FYI that bug got fixed).

The more intimate the knowledge of how things works, the better your
understanding of where things could intertwine and muck up…. the better your
chances of finding critical bugs that causes crashes or otherwise.

Filed under: mobifx, mobile, Planet, QA, QMO, Uncategorized Tagged: QMO

March 12, 2012 06:47 PM

Our User Research team just finished a field study that explored the differences in how people use browsers and apps on mobile devices (phone and tablet). The goal was to understand what value a browser should provide on mobile devices and identify opportunities for Mozilla in the mobile browser space.

One of the key findings from the study was that while generally, single purpose apps are more widely used than web browsers on mobile devices, they do not entirely replace them either. Browsers really shine when people are trying to  find answers to things (searching).

So where apps answer the problem of  “I need to do ____”, browsers are still the go to solution to answer “I need to know ____”.  With this in mind, we’ve been working on how to improve search in mobile Firefox, by making it quicker and more useful.

Building on our Awesomebar experience (showing lists of bookmarks and history, ranked by frecency), we have added search suggestions that display simultaneously with your Awesomebar results. Once no Awesomebar results remain, users still have a multitude of searches they can jump to, and across multiple providers.

This is a work in progress, and feedback is welcome.

March 09, 2012 04:22 PM

I implemented the W3C Geolocation API V2 specification ahead of the other browsers. In this API, web sites can not only request a latitude and longitude but also request a physical mailing address. It does this by ‘geocoding’ the latitude and longitude pair using a third party service.  These services typically cost a lot.  On the desktop, I disabled this feature after a few months of it live.  After the removal, I did not receive any emails that things ‘broke’.  Hence, I believe there is little demand for V2.

I am going to remove support for V2 in Mozilla.  In the future, if there is a demand, I think the right approach is to expose geocoding to the web as a separate API.  Stay Tuned.

March 08, 2012 12:02 AM

So there’s 4 types of crashes within the Fennec Native world right now.

1) Crashes that occur due to the Native UI which is caught by breakpad

2) Crashes that are caught by breakpad

3) Crashes that are caught by the OS but not breakpad

4) Crashes that neither breakpad nor the Android OS catches

In all of these cases, if you run into a crashing bug within fennec having a logcat helps out a lot.  For crashes that happen in Native UI, those java crash stacks do appear in the logcat.  In the other cases, it does help sometimes to see what the logcat is spewing during the time the crash is happening.  So please please please try to use logcat and attach it to the bug.  ( http://aaronmt.com/?p=503 or just as good is downloading alogcat.  Pro tip: To get timestamps use command line : adb logcat -v time )

So let’s go back to point 1.  So if you look at a crash now within Socorro that has a java crash :

https://crash-stats.mozilla.com/report/index/009e2d28-1fef-4b63-971c-efd782120217

You can see a new field that has the Java Stack!  Yes, thanks to the socorro team and cpeterson, esp lars, and laura.  That is hotness.

Point 2 is a matter of looking at Socorro.

Point 3/4 … if it’s released out in the Android Marketplace, there’s methods of getting the crashes from there.  Otherwise : http://www.jnchen.com/blog/2011/11/updated-gdb#the__comments  I haven’t tried to setup jimdb yet  There’s other methods for nonFennec related apps.  http://stackoverflow.com/questions/601503/how-do-i-obtain-crash-data-from-my-android-application

JimDB is probably going to be my second next project to look at leisurely at home.  Currently, I want to finish getting robocop up and running and getting tests in for robocop.

Filed under: mobifx, mobile, Planet, QA, QMO, Uncategorized Tagged: mobifx, mobile, Planet, QMO

February 18, 2012 08:05 PM

The URL you requested could not be found.

February 16, 2012 06:18 AM

This year’s FOSDEM was a special one for me. It was the first time I attended it as a Mozillian! I had already met quite a few European community members at MozCamp Europe last year but this FOSDEM was a great opportunity to meet even more Mozillians face-to-face. I stayed at the Mozilla DevRoom most of the conference but also spent some time catching up with my fellow GNOME hackers.

Chris and I gave a “State of Firefox Mobile” talk on Sunday. I usually don’t share my slides because they tend to be too short in content to be useful. However, we wrote some speaker notes that give enough information and context on what we talked about. So, here’s the deck alternating between slides and speaker notes—I wish Speaker Deck had proper support for speaker notes…

All in all, I had a great time at FOSDEM this year! PS: The weather during the conference was quite special too—in a painful way!

February 09, 2012 04:09 PM

Today, the SafeBrowsing rewrite me and Dave Camp have been working on for several months finally landed in the Mozilla Nightlies, and it should be part of the Firefox 13 release, narrowly having missed Firefox 12. It reduces the disk footprint of our anti-phishing and malware protection from about 40-50Mb to 5-6Mb, changes all related I/O from pure random access to a single serial read, and refactors a single 4000+ line C++ file into a bunch of modules. An earlier part of this work landed in Firefox 9 and reduced the memory footprint from potentially up to 40-100M to 1.2M, as well as removing the need to do some random I/O on every page load.
Aside from the performance gains, the reduced footprint is an essential step to enable us to extend our SafeBrowsing protection to Mobile devices, which is why we undertook this in the first place.

It was an interesting assignment, and being my first real project for Mozilla, a bit more involved than we thought at first. I blogged in July last year about our plans for this feature. Some of the optimizations we had in mind didn't work out, while others did end up being implemented.

Eliminating the host keys

One of the things touched upon in the previous blog post was that we used to store 2 32-bit hash prefixes for every blocked entry: one encoding only the host and the other encoding the full URL. Strictly speaking, we only need the full URL part. The old SQLite based code used the host key to SELECT and load all keys for a certain domain at once, but our new in-memory prefix-trie based approach has no such needs. However, as Justin Lebar alread touched upon in the previous blog, this does significantly increase the likelihood that we get a false positive. We now expect to have a false positive for every 7000 URLs visited. This will not cause us to block out any legitimate sites, as any positive hit in the local database is queried against the full, 256-bit hash at a remote server (hosted by Google, who provides the SafeBrowsing data).

This does mean we will increase the traffic to this remote server by a large factor. Scary as it may sound, some back-of-the-envelope estimates shows its not really that bad: say there are about 420M Firefox users, browsing for 8h/day. They load on average 1 URL per second. This means about 140M URL loads per second, causing about 20000 hash requests per second to Google. Google confirmed they can handle this with ease.

Now, there is still a problem when doing this: any collision will appear for all users on exactly the same URLs. This means that if you're unlucky enough to be a a site owner that has an URL that happens to collide, every visitor to your site will have a slightly slower browsing experience. Even worse, should you get linked in a popular forum, or be in the news, there will be a storm of false positives to the server all at once. We thought this to be problematic enough that we implemented a workaround: every user will generate a unique randomization key and re-randomize all his hashes with it. Collisions will happen on a different URL for every user, and consequently also be much better spread through time.

Eliminating chunk numbers

After some discussion, it turned out eliminating the chunk numbers isn't as easy as hoped. First of all, the observation in the previous blog posts that chunk expires only seem to happen when the chunks are in fact old, doesn't hold after observing the protocol for a longer time. It also happens very regularly that a chunk is added, deleted, and added back again, particularly in the malware list. In those cases, it is important to know which add chunk a delete is referring to, so it won't delete the later add. It would still be possible to deal with that if the server recalculates the prefixes to send for every client, but this is less efficient on the server side compared to the bigger, more static downloads that the server can point to now, and which are easily mirrored on Google's network.

Sub prefixes compress harder

In line with the previous paragraph, it happens that we receive sub prefixes for add prefixes we never received. These must be kept around until we receive an expire for them, as we can't know if the add they belong to is outdated or just not downloaded yet. Note also that we usually receive updates backwards, i.e. the most recent data will be sent to the clients first, as it's the one believed to be most relevant. Because sub prefixes contain both an add and a sub chunk, they are also bigger than add prefixes. This causes the eventual size of the database to be a bit more than the minimum guessed in the previous blog post, which more or less ignored sub prefixes entirely. If you peek in your profile, you can see that the goog-malware-shavar.sbstore will tend to be the biggest file: this is exactly due the many sub prefixes in the malware list.

Detection performance

It should be noted that these improvements are purely focused on the footprint of the feature. They will improve the resource usage of the browser, but they do not change the detection performance in any way.

NSS Labs Report

In what is somewhat of a funny coincidence, the same day I am writing this blog NSS Labs published a report "Did Google pull a fast one on Firefox and Safari users?". The main points of this report shouldn't be much news as I pointed out over half a year ago the discrepancy between Chrome, and Firefox and Safari in my previous blog post, as well the reason ("Performance differences between Firefox, Chrome and Safari").

I have two remarks to the report: one, as I've already pointed out in the past, false positive control is an important part of effective malware detection. Internet Explorer flags many malware sites, but it also flags legitimate sites, undermining the true effectiveness.

Secondly, the problem isn't so much that the "new" SafeBrowsing protocol is proprietary or non-documented; it's implemented in Chrome and Chromium is open source, so at the very worst we can go study that code to see how to implement it. The problem is that permission is required to use Google's SafeBrowsing servers, and Firefox does NOT have permission to use the download protection list. Edit: Please see the statement from Ian Fette below.

February 07, 2012 07:45 AM

Hello, Firefox Mobile testers!

Our goal is to provide you with mobile news and guidance towards how and where you as a tester can help out!  Thanks for helping out; your input is greatly appreciated!

What’s New in Fennec Native UI this week?

• ADUs : Aurora -  1,229 (+12%) ; Nightly -  1,196 (+4%) ; Beta -  27,042 (+3%)
• This will be the last Weekly letter, please refer to the MTD newsletter for future news
• [mobiletestdrivers@mozilla.org; https://wiki.mozilla.org/Mobile/Testdrivers_Program]
• Please make sure that you are on the most current version: there are crash fixes in 2/1 as well as 1/19 build
• Features to look at now: https://wiki.mozilla.org/Fennec/NativeUI/NightlyFeatures

Nightly:

• concentration is currently more on beta readiness
• https://wiki.mozilla.org/Fennec/NativeUI/Showcase2-1

Aurora:

• stabilization concentration : Here are searches and stuff where people can help out!
• http://shizen008.wordpress.com/2012/01/24/war-on-crashes/#respond
• If you have any questions, please comment.
• Please see the testing areas, tips and tricks in how you can help!

What’s Coming up in Fennec:

• Sync Support
•  Split-APK; XUL for Tablets, Native for Phones
•  Profile migration
• From XUL to Native profile migration
• L10N
• Required for String Freeze for Fx11 (Jan 30th): query
•  Single-locale APKs
• Feb 27 2012: Public Announcement at Mobile World Congress
• March 30 2012: Final Release

How to download the latest Fennec Native UI build:

• Enable ‘Unknown sources’ in Settings | Application Settings on your Android device
• Go to: http://nightly.mozilla.org
• Click and download the Android installer under the mobile section

Testing Areas, Tips and Tricks:

• Please test on various devices that can run Fennec Native
• Head to your favorite sites and file bugs on sites that do not work or don’t meet your expectations
• Play with the bookmarking and recent visits as well as the session history (forward/backwards navigation)
• Download the Zippity Addon: http://people.mozilla.com/~mfinkle/fennec/addons/testharness-mobile.xpi and go to about:testharness to perform various tests
• Explore away with testing these features https://wiki.mozilla.org/Fennec/NativeUI/NightlyFeatures
• Use logcat and other tools to monitor your logs to help your bug reports.  There are options:
• You can install Android SDK such as : http://aaronmt.com/?p=503
• a system monitor tool such as : https://market.android.com/details?id=com.eolwral.osmonitor&hl=en
• or alogcat : https://market.android.com/details?id=org.jtb.alogcat&hl=en
• alogcat allows you to send your log elsewhere.
• Nightly builds now support Flash (on Android 2.3 and Android 2.2)
• Note: you will need to download and have installed the latest version of the Flash Player from the Android Market
• For more tips and tricks see : http://shizen008.wordpress.com/2012/01/22/exploratory-testing-crash-course-2/#respond

We want to hear from you!

• If you think you’ve discovered a bug, you have options:
• Discuss the issue in this email newsgroup
• you can file it in Bugzilla (http://bugzilla.mozilla.org) under the product: “Fennec Native”, or just follow this link: https://bugzilla.mozilla.org/enter_bug.cgi?product=Fennec%20Native.
• Newsgroup archive is available : https://mail.mozilla.org/pipermail/android-mobile-nightly-testers/
• Feel free to discuss issues you encountered in this email newsgroup!
• You can also feel free to message this mailing list if you have questions in regards to features: https://lists.mozilla.org/listinfo/dev-platforms-mobile
• Any feedback on the newsletter can go to: Naoki at nhirata@mozilla.com
• To subscribe :  please go to https://mail.mozilla.org/listinfo/android-mobile-nightly-testers

Regards,
The Mobile QA Team

Filed under: mobifx, mobile, Planet, QA, QMO Tagged: mobifx, mobile, Planet, QA, QMO

February 02, 2012 02:12 AM

I wrote this back in October.  Never posted it.  Here it is for posterity and maybe some quick reflections.

Start-up performance and memory usage have been the two of the biggest concerns our users have had with Firefox for Android.  On the fastest Android devices, the browser starts up in about 2 seconds.  We, and our users, believe that this is completely unacceptable.  We have been exploring ways to improve both startup speed and memory usage.  One of the outcomes has been to build a prototype that uses Android’s native UI instead of XUL.  Although not a silver bullet, this prototype shows big wins in both areas.

Historically we’ve built our Android user interface with XUL.  XUL is a very flexible UI toolkit.  This flexibility comes at a cost. It requires that we have to load all of Gecko, our rendering engine, before being able to start using XUL.  So, before we can show any browser UI, we have to load all of Gecko.  A lot of progress has been made to improve Gecko startup, but we aren’t able to provide the same startup experience that native Java widgets can provide.  Just to be clear, this isn’t actually because XUL is slow, it is just that, on Android, bring up native widgets is very fast and loading libraries is very slow.

Our prototype shows that we have a 6MB RSS memory win when comparing our current build to a Fennec nightly build.  This doesn’t include the RSS usage caused by a second ‘child’ gecko process.  We can have a fully functional Awesome Bar up and ready for you in under 300ms.  Keep in mind that this is a prototype and the actual numbers of a more full featured browser will vary.

A native UI will have some challenges of its own to overcome. We’re coordinating with the Jetpack project to build strong support for extensions. We’re talking with our localization teams about how to ensure we support users around the world.

Our hope is to build future versions of the Firefox for Android user interface using native Java.  Our engineering teams are already taking this project on with the aim of building this technology into the Firefox for Android experience. It’s too early to estimate when we’ll be ready to replace the XUL UI, but the team is working quickly and with focus.

We have a lot of work to do, and you can help.  If you would like to get involved, especially if you have experience building native Android applications, now is the time. Take a look at https://wiki.mozilla.org/Fennec/NativeUI for more information, or grab the source from http://hg.mozilla.org/projects/birch/.  Also see the mozilla dev-planning mailing list for a discussion.

January 25, 2012 04:35 AM

I was asked to give a presentation on the recent developments in Firefox Mobile for the Mozilla Vision 2012 conference in Tokyo. It gave me a chance to reflect a bit on what we did, why we did it and how things are going. The “what” in this case is rewriting the UI for Firefox Mobile using native Android widgets. The “why” can be summed up in the following goals:

• Faster start-up time
• Support for Flash
• Use less memory

We have been fairly “heads down” working on native Firefox for Android over the last 3 months. Re-writes are scary. It’s a race to re-implement existing functionality while adding all new bugs. We are finally to the point in the project where things are settling down. We are focused on stability issues, getting ready to release the native version to a larger audience. As for the primary goals, we have good news:

• Start-up time is many times faster than the XUL version. Launching via the icon is almost instantaneous.
• Flash is supported on Froyo and Gingerbread. We need to reverse engineer the changes made for Honeycomb and ICS. There is no documentation for this work.
• With a single-process, we have reduced memory quite a bit. We still can get killed in the background by Android – it’s supposed to do this – but when this happens, we start up very quickly and restore your session.
• We still support add-ons using the native UI!

I’m looking forward to being able to move forward again, designing/implementing new features on a solid foundation. We have plenty of new experiments and projects waiting to move forward.

Mozilla Vision 2012 was a great conference and very well attended. I’m very glad I had the chance to participate. Here is the link to my Google Docs presentation. It has a bit more details.

… and go grab a Nightly and see the changes for yourself!

January 23, 2012 07:30 AM

Found this snippet of code last week and it works beautifully to create an Android screenshot at the command line without going through the hassle of using DDMS.

Pull the current frame buffer from the Android device (phone or tablet) to a local file.

adb pull /dev/graphics/fb0 fb0

Convert and copy the frame buffer output block size to 1920 bytes, copy only 800 bytes, read from local frame buffer and write to a new file.

dd bs=1920 count=800 if=fb0 of=fb0b

Use FFmpeg to record a single raw video frame, and convert it to RGB32 pixel format (480×800 resolution) outputted to a single PNG file.

ffmpeg -vframes 1 -vcodec rawvideo -f rawvideo -pix_fmt rgb32 -s 480x800 -i fb0b -f image2 -vcodec png fb0.png

Stick this all in a nice Bash script and you’re good to go.

January 23, 2012 02:56 AM

Some people wonder how I find bugs.  It’s not just a matter of running a test case, but to test around the bug.  (I explained how to test around a bug in an earlier blog).  Thinking of each of these items as a state, and running various permutations in which is likely to find bugs is what I do.  It is potentially possible to automate this type of testing, when I stopped to think about it.  It’s similar to the test fuzzing, but just moving steps around and such.  Someone would still have to run a verification on the fuzz tests, though.  Anyways…

I posted this previously on my blog with little explanation about this list.  There are one off bugs within Fennec that you can do from a black box perspective.  (ie not knowing anything about how things are coded). Here, I’d like to take the time out to show that one small action can make the difference between finding/reproducing a bug and missing a bug.  Below is a list of things that you can try to test around a bug.  ie, follow the steps that you would do + try one other different thing such as rotate the device or place one of these steps instead or insert the step before another step.  Try combining it with the test web page list that I have in a previous entry.

I don’t look at just what the target of the tests are; I look at the whole device from start to finish while I running the tests. Why?  Because even though I am testing to verify the tests, something else may occur in the meantime while running the tests.  It has to do with Inattentional blindness which is best explained ( http://www.psychologytoday.com/blog/and-all-jazz/201009/must-read-the-invisible-gorilla )  The more you can remove your inattentional blindness, the more you can find bugs.  Cognitive behavior plays a huge part in designs for ui as well.  It’s good to know the science behind the ui/artwork.  I admire good ui designers.  Mozilla is very fortunate to have talented ui designers like Madhava and iBarlow.  (Ya, I like saying iBarlow… though he isn’t a product of Apple).    But anyhow that’s a side story.

One off bugs:
- Move to SDcard; stored on device *
- change orientations *
- difference between URLbar text typing and text field typing  *
- URLbar is an android widget and will show difference in behavior
- different VKBs : simeji (double byte/commit), swype, swiftkey, default keyboard
- these vkbs have shown differences
- chrome versus content *
- flash versus webm *
- iframes *
- viewport versus non-viewport
- global history versus imported history *
- Sync *
- CPU instruction set : omap vs neon vs tegra *
- Arm version (6 versus 7) *
- Android OS versions 2.2, 2.3, 3.0, 4.0 *
- Hardware keyboard vs VKB (virtual keyboards)
- RTL
- double byte characters
- international date/time
- new tab versus current tab *
- local page (about: pages) versus remote pages (other urls) *
- uri (file:// versus http versus youtube versus https ) *
- web gl *
- quit * vs force quit (quitting will not restore the tab, force quit will restore the tab)

* asterisked are some actions that may make a difference in terms of crashing.

TIPS : When you try to go to a web site, try one of these small things and try to pay attention to what you do when you are testing.  Sometimes it’s hard to remember every thing you do, I tend to either reboot my device or quit and restart fennec to get me to a known state.

When I do find a bug, I try to reproduce the bug right away; but I restart the fennec and device to verify that I can reproduce from scratch.  Once I find the bug, I sometimes try to see what I can remove out of the steps to try to get to the shortest path to the bug.

Other information that helps are logcat, as well as crash ids from about:crashes, screenshots, and any other information you can provide such as version number and mobile device name.

Also other things I do is to try to see if the bug already exists, etc. etc.  It’s not always easy to do all these things and at times I do fail to find duplicates, or another thing listed in here.  I try the best that I can in the given amount of time I have.  Hopefully these tips will help you find bugs within fennec and help us improve the product!  Good luck and hope to read your bugs in bugzilla!

Filed under: mobile, Planet, QMO, Uncategorized

January 22, 2012 11:02 PM

So I ended up getting a crash course in videography.  I have to do this video shooting of mobile devices to get performance numbers.  Rainer was kind enough to take some time out to explain a lot of things to me yesterday which without his help would have probably made my work ten times more difficult.

I changed a lot of what I did since the first time I did the shooting, which unfortunately means redoing some of the numbers so that everything is consistent.  Rainer isn’t the only one I would like to thank for helping me out.  I would like to thank Bob for his advice, as well as Clint for the automation and Spencer for his help.  Here is a list of things that made a huge impact from getting 9 set of numbers from 6 and a half hours to about 3 hrs or so.

1) Video shooting is now semi automated, thanks to Clint.  The location for the video tool is found here :  https://github.com/ctalbert/crossbrowser_video_tool

The phones are now rooted ( Droid Pro, Nexus S, Galaxy S II) in order to have this tool work.  (need it in order to kill the web browser process).  For any bug I encounter, I am slowly fixing it and doing pull change requests.  There’s nothing major so far in terms of the fixes I did.  Starting to learn to get used to github because of this part of the project.

2) Shots are done continuously as much as possible (Bob’s advice).  Stop starts not only wear down the camera a lot more in terms of overheating and such but it slows down the process for having to wait for the camera to be ready, etc.

3) The video framing is 640 x 480 using the Canon 60 D (Rainer’s advice).  I had tried to use a Sony DSC-HX9V to do the shoot, but I ran into issues.

a) The video shooting resolution for 60 fps can only be done in 1920×1080.  This means any editing that I need to do or any compression that I need to do or for that matter, moving the files are going to take a lot longer than something that’s 640 x480.  It’s a difference of a 20 gig file versus a 2 gig file.

b) The video format is a proprietary Sony video format and will automatically get converted to 30 fps from 60 fps in Final Cut Pro.  Yes, I could probably use some other program to convert the format to retain the 60 fps, but I would encounter problem a.

I did all sorts of stuff on my end to make sure that it wasn’t just me.

4) Removing the dependency that I had with Spencer.  As much as I like working with Spencer, there’s a sense of urgency for this project.  I don’t necessarily need him to do the post production when all I need to do is get numbers.  I purchased Final Cut Pro (for myself) as well as Compressor.  Spencer taught me how to do some of the video shooting myself (Not talking about the pro quality of stuff that Rainer and Spencer can do … but just enough to get the job done).  Without having to wait for the video files as much that cut down on a lot of time.  (Not to mention that I’m working with smaller file sizes now).

I had no knowledge of this material prior to late December when I was asked to take this over.  I don’t mind working with people and learning.  It was a pleasure and continues to be so working with these kind folks.   They helped me out making the time it takes to make the videos more manageable.  I now know a bit more about videography (thanks to Rainer), photography (thanks to Bob), and how to use the Canon 60D (thanks to Spencer).  Not only that the time to get the numbers necessary is now halved!

Filed under: mobile, Planet, QA

January 21, 2012 10:56 PM

After trying to see what is working and what is not working, I found that I still have to change up how I do things in crash reporting for mobile.  Based on what I am trying to figure out and speaking to Kairo, Kairo has been kind enough to create some reports for me to help me do my analysis faster:

https://crash-analysis.mozilla.com/rkaiser/2012-01-16/2012-01-16.fennec.beta.10.0.devices.html

https://crash-analysis.mozilla.com/rkaiser/2012-01-16/2012-01-16.fennecandroid.nightly.components.weekly.html

Since my responsibilities can be time consuming, these reports are helping me out in terms of figuring out correlations faster or getting a better handle on them.

Cheers to Kairo for helping out with this.

Speaking to smooney and chofmann as well as marcia, I realized that I have to change other things as well.  It’s still a work in progress but there are crash analysis being done for mobile.  If you have any further input in how I can make things better, please let me know!  I would love the feedback.

Filed under: mobile, Planet, QMO

January 17, 2012 05:40 PM

Hello, Firefox Mobile testers!
Our goal is to provide you with mobile news and guidance towards how and where you as a tester can help out! Thanks for helping out; your input is greatly appreciated!

What’s New in Fennec Native UI this week?

• ADU update : Aurora – 913 (+17% from last week) ; Nightly – 1044 (+7% from last week)
• Newsgroup archive is available : https://mail.mozilla.org/pipermail/android-mobile-nightly-testers/
• Feel free to discuss issues you encountered in this email newsgroup!
• Features to look at now: https://wiki.mozilla.org/Fennec/NativeUI/NightlyFeatures

Nightly:

• crashing from rotation is mostly fixed, there are still some crashiness to be investigated
• page size flickering no longer happens
• tab restore (Bug 703450/Bug 697858)

Aurora:

• stabilization concentration
• Please see the testing areas, tips and tricks in how you can help!

What’s Coming up in Fennec:

• “Show character encoding” (Text encoding) preference
• Sync Support
• Jan 16 2012: String Freeze
• Jan 16 2012: First Run Walk-Through
• Jan 30 2012: Beta Declare
• Feb 27 2012: Public Announcement at Mobile World Congress
• March 30 2012: Final Release

How to download the latest Fennec Native UI build:

• Enable ‘Unknown sources’ in Settings | Application Settings on your Android device
• Go to: http://nightly.mozilla.org
• Click and download the Android installer under the mobile section

Testing Areas, Tips and Tricks:

• Please test on various devices that can run Fennec Native
• Head to your favorite sites and file bugs on sites that do not work or don’t meet your expectations
• Play with the bookmarking and recent visits as well as the session history (forward/backwards navigation)
• Download the Zippity Addon: http://people.mozilla.com/~mfinkle/fennec/addons/testharness-mobile.xpi and go to about:testharness to perform various tests
• Explore away with testing these features https://wiki.mozilla.org/Fennec/NativeUI/NightlyFeatures
• Nightly builds now support Flash (on Android 2.3 and Android 2.2)
• Note: you will need to download and have installed the latest version of the Flash Player from the Android Market

We want to hear from you!

• If you think you’ve discovered a bug, you have options:
• Discuss the issue in this email newsgroup
• you can file it in Bugzilla (http://bugzilla.mozilla.org) under the product: “Fennec Native”, or just follow this link: https://bugzilla.mozilla.org/enter_bug.cgi?product=Fennec%20Native.
• You can also feel free to message this mailing list if you have questions in regards to features: https://lists.mozilla.org/listinfo/dev-platforms-mobile
• Any feedback on the newsletter can go to: Naoki at nhirata@mozilla.com
• To subscribe : please go to https://mail.mozilla.org/listinfo/android-mobile-nightly-testers

Til next time,
The Mobile QA Team

Filed under: mobifx, mobile, Planet, QA, QMO Tagged: mobifx, mobile, Planet, QA, QMO

January 17, 2012 07:18 AM

One can enable ADB over WiFi from any Android device with the commands:

setprop service.adb.tcp.port 5555
stop adbd
start adbd

And one can disable it and return ADB to listening on USB with

setprop service.adb.tcp.port -1
stop adbd
start adbd

If one has USB access already, switching to WiFi is a breeze. From a terminal on a computer that has the device connected via USB, issue the commands (replace the IP with the IP of the device on the network):

adb tcpip 5555
adb connect 192.168.x.x:5555

To tell the ADB daemon return to listening over USB:

adb usb

January 10, 2012 03:11 PM

Filed under: mobifx, mobile, Planet, QA, QMO, Uncategorized

January 01, 2012 05:58 AM

This upcoming Friday, the first week of the new year we would love for you to solicit your support towards testing and contributing to the process of qualifying the new native version of Firefox for Android on the Aurora channel as part of our Rapid Release testing cycle.

This event is open to all: newcomers, experienced testers, experienced developers, and people interested in testing.

If you’re keen on testing, we would like for you to use the new version of Firefox either on your Android phone or tablet, and take a close look at the latest builds in order to assist us in identifying any noticeably major issues found, and ensure that all feature functionality that is included in this upcoming release is on its way to a feature and testing complete state. We will also be looking at website compatibility, and device compatibility. No testing experience is required.

To cover the work throughout the whole day we have created an EtherPad test-plan. Please feel free to read and use it as a companion during the testday event. There will be moderators at hand in the IRC channel: #testday, to answer any questions you have.

Together with your help we want to make this testday a success and ensure the high quality of Fennec for mobile devices for all of our users world-wide. If you have time on Friday, January 6th, 2012, please join us on IRC, we will have Mozilla community and testers on hand to help answer any of your questions.

Your testing and feedback is highly valuable, and we hope to see you attend our testday event.

December 30, 2011 08:41 PM

December 28, 2011 01:31 AM

Filed under: mobifx, mobile, Planet, QA, QMO, Uncategorized Tagged: mobifx, mobile, Planet, QA, QMO

December 23, 2011 09:23 PM

Oh yes.. this means that Fennec Native crashes are now being tracked separately! See for yourself: https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/12.0a1/7

Filed under: mobile, Planet, QMO Tagged: mobile, Planet, QMO

December 23, 2011 08:15 PM

Welcome Firefox Mobile testers!
Our goal is to provide you with mobile news and guidance towards how and where you as a tester can help out!

This Week’s Headlines!

• Feature Freeze : 12/20 !
• Context Menus for text fields
• about: Screen touch ups
• Easier Searching
• Newsgroup archive is available : https://mail.mozilla.org/pipermail/android-mobile-nightly-testers/
• Feel free to discuss issues you encountered in this email newsgroup!
• Features to look at now: https://wiki.mozilla.org/Fennec/NativeUI/NightlyFeatures

What’s New in Fennec Native UI this week?

• Context Menus for text fields
• Flash : Click to Play in preferences
• Font size inflation button in preferences
• about:home screen improvements
• about:addons screen improvements
• Search engine(s) shows at bottom of the list
• Search Magnifying glass to search words in urlbar
• type a word and tap the magnifying glass on the right

What’s coming soon to Fennec on Android?

• Find in Page
• Robotium support
• Character Encoding
• Remodel of the Tab Menus
• And more! (note: the above have to meet the 12/20 deadline to make it in this release)

How to download the latest Fennec Native UI build:

• Enable ‘Unknown sources’ in Settings | Application Settings on your Android device
• Go to: http://nightly.mozilla.org
• Click and download the Android installer under the mobile section

Testing Areas, Tips and Tricks:

• Head to your favorite sites and file bugs on sites that do not work or don’t meet your expectations
• Download the Zippity Addon: http://people.mozilla.com/~mfinkle/fennec/addons/testharness-mobile.xpi and go to about:testharness to perform various tests
• Explore away with testing these features https://wiki.mozilla.org/Fennec/NativeUI/NightlyFeatures
• Nightly builds now support Flash (on Android 2.3 and Android 2.2)
• Note: you will need to download and have installed the latest version of the Flash Player from the Android Market

We want to hear from you!

• Feedback Questionnaire : What are the 3 top things that you think needs to improve? Please reply to this mailing list: android-mobile-nightly-testers@mozilla.org
• If you think you’ve discovered a bug, you have options:

1. Discuss the issue in this email newsgroup: Android-mobile-nightly-testers@mozilla.org
2. you can file it in Bugzilla (http://bugzilla.mozilla.org) under the product: “Fennec Native”, or just follow this link: https://bugzilla.mozilla.org/enter_bug.cgi?product=Fennec%20Native.
3. You can also feel free to message this mailing list if you have questions in regards to features: https://lists.mozilla.org/listinfo/dev-platforms-mobile

• Any feedback on the newsletter can go to: Naoki at nhirata@mozilla.com
• To subscribe : please go to https://mail.mozilla.org/listinfo/android-mobile-nightly-testers

Til next time,
The Mobile QA Team

Filed under: mobifx, mobile, Planet, QA, QMO Tagged: mobifx, mobile, Planet, QA, QMO

December 17, 2011 11:51 PM

When I first started, Dougt had helped me out with bugzilla searching as well as recommended setting up firefox with the Quicksearch.  Getting a bug number and looking at the bug has never been easier (minus having firebot around).  Yay for Beltzner’s Youtube post:

 

Filed under: mobifx, mobile, Planet, QA, QMO Tagged: mobifx, mobile, Planet, QA, QMO

December 16, 2011 05:29 PM