(Smart)Find for Firefox 3.*

Inspired by our own need and other's, a couple of friends (André, Roberto and Tomaz) and I decided to increment Firefox' default find feature.

Story

If you use Firefox, you had probably used the Firefox' findBar already. It is the simple and intuitive way users have to search for words in a web page. The main thing we "miss" is that it requires the user to type the exact (set of) word(s) he searches for to actually find it. Sometimes, however, lazy enough users *like us* want to just give the findbar a "clue" of what we want to find in the page, and even often just do not know. The result of that was the SmartFind addon for Firefox 3.x. From its site we have some usecases of SmartFind:

1. "Schwarzenegger". This looks easy when you are looking at the word, but what if you do not have any idea what to write? Then you wonder "I would like to write something like "chuazenger" and for it to find similar words in the page".
2. As another example, when you are on a page where accents are used and your keyboard is not configured to type such accents (~^`), the traditional find method will not be able to match with any word.
3. You are just lazy like us and terrible in orthography :)
   

HOW

Smartfind ranks how similar each word in the page (yeah, that might take time depending on the webpage ... heuristics exists to speed it up, but new ones are welcome) is to the given word (input by the user). For such, we are implementing the levenshtein distance metric. The "how similar" can be trigged by the user through the Edit->SmartFind menu, to be more or less restrictive.

Well, in practical terms, whenever Firefox' original find method does not find something, SmartFind takes place and hitting a aditional "enter" fires its actition ...

If it is still not clear, see sshots bellow:

User is not from Austria and does not know how to spell this-big-name-above.

SmartFind finds it for him.

Disclaimer: This is just the first and quickly implemented public release, so there are some known problems:

• Improve the way it gets text content from the webpage (better xpath expression, which ignores "object" , "style" , "script" tags' text content).
• Fix problems with line break (lack of "br" tag) .
• Implement an user-intuitive way to walk through the list of most similar items found: currently we are static to the top of the list.
• Implement a fuzzy third state (similars ?) while comparing chars that could make SmartFind work much better: "for example, consider 'ë' as not completely different from 'e' or 'é' but similar". That done, the Finnish word "päivää" would be more similar to "paivaa" and so on ...
  
• Port it to Fennec (Firefox-Mobile) browser.
• Make it work with other Firefox addons, including FindInTabs.
• Implement SoundEx into it (?).

--Antonio Gomes
tonikitoo at gmail dot com

Open source browsers war: Mozilla and Webkit raw builds numbers on Maemo (ARM)

The big picture

Bosses are only pleased when they get numbers and charts in reports on top of their tables. At this round, we (André, Diego, Fernanda and I) had to benchmark Mozilla and Gtk-Webkit on arm, and so we did ... Text below is an informal summary of the official report.

Scenario

• Experiments were performed using Nokia N810 Internet tablets (400MHz CPU and 128Mb of RAM memory) with Chinook installed.
• Applications under test were GTK+ embedding sample browsers from both Mozilla (TestGtkEmbed - available from the mozilla-central repository) and WebKit (GtkLauncher - from the WebKit trunk), cross-compiled in Scratchbox 1.0.8, gcc-2005q3-2.
  

About the tests

These were the items measured:

1. Page load speed

The page load test focuses on measuring the absolute and relative time needed by each browser to open a given set of locally stored webpages. The test is driven by a JavaScript script that fires the load of each page in the test set. Both the time speed for each Web page to load (relative time) and the total time taken by loading the whole set (absolute time) are measured. The test set is formed by 37 real-world webpages fetched using the httrack crawler and is accessible over an Ad-hoc wi-fi network via the Apache Web server.

2. Memory and CPU consumption of 1)

The goal of this test is to evaluate how well browsers manage system memory during the page load test (above): virtual and physical memory allocated by each browser were monitored and printed out in a comparing chart. As such, a Bash script was developed to "watch" system memory and CPU numbers. It is basically a timer used to poll at every 1 second the browser's virtual and physical memory values from "/proc", and CPU usage from "top" (in batch mode).

3. Javascript engine performance.

Both browsers were ran against Dromaeo and SunSpider Javascript test suites and memory consumption during these tests was measure (same way as in 2).

4. CSS compliance

Both browsers were ran against Acid3 CSS test suite.

Results and Charts

As there is no such general browser benchmark suite (is this even possible ?), we just developed your own tools (bash and JS) for those item above that do not have renowned public benchmarks available (pageload and resource consumption).

ps: I tried Mozilla's Talos suite, which seems fine to test Mozilla but it is not portable for other browsers.

1. Page load speed

Mozilla's and Webkit's page load speed against the given pageset (see table below).

Individual pageload speeds (in ms).

DISCLAIMER

• Original page set was formed by 85 webpages, from Talos Mozilla Test Suite. Although TestGtkEmbed ran well through the entire original testset, GtkLauncher always got OOM-killed after a while running the page load test, due to lack of memory (see memory chart in Memory Consumption section). Then, from the original 85 webpages, 37 were chosen to make GtkLauncher to finish this test.
  
• 10 out of 37 of the remaining webpages in the pageset contain non UTF-8 characters (Russian, Japanese, Chinese, ...). While WebKit misrendered most these fonts, Mozilla went fine for all. Example showed below:

www.3721.com in TestGtkEmbed

www.3721.com in GtkLauncher

2. Memory and CPU consumption during 1)

Memory consumption while doing page load test in 1).

UPDATE: VIRTUAL AND PHYSICAL MEMORY LABELS ARE CHANGED HERE.

CPU load while doing page load test in 1).

3. Javascript engine performance.

Dromaeo numbers.

SunSpider numbers.

Browsers memory use while doing Dromaeo.

Browsers memory use while doing SunSpider.

4. CSS compliance

Mozilla on Acid3.

Webkit on Acid3.

Conclusion

Some outstandings from the numbers:

• Mozilla managed better memory while doing page load tests, although Webkit was faster. It might probably been had affected by the fact that Mozilla rendered well all non-western chars, Webkit fails.
• Webkit was faster and used less memory while doing both Dromaeo and SunSpider test.

UPDATE: Some things that have to be pointed out about my Mozilla build are:

• I do not jemalloc enabled, but would love to.
• Mozilla guys are doing some amazing job on speeding up their Javascript engine: tracemonkey will probably get things much (5x at least ?) faster.
  

ps: I personally would not mind to do a 2nd recond of tests and charts w/ these two items above enabled in my Mozilla build.


--Antonio Gomes
tonikitoo at gmail dot com

Prism for maemo updates

The Mozilla Prism guys mfinkle and plasticmillion are doing a great job heading to 1.0, and happily we are about to start to get prism changes for maemo upstream.

Below some nice sshots of the current prism maemo port, prism-maemo_0.0.7-1 (which is just out), running on chinook.

Prism on meebo.com

Prism on mibbit.com

--Antonio Gomes
tonikitoo at gmail dot com

Mozilla/Firefox Summit 2008

So, the much anticipated Mozilla Summit 08 has just finished, and regardless some unforeseen, I truly believe that most of the 400 (+-) attendees had an amazing time, as so did I. Follows some of my highlights:

• Dan's team did really well on organization ...
  
• I had chance to see some really nice mozilla guys again including: both the father and grand-pa :) of mozilla mobile, dougt and choffman, respectively; the long term mozilla contributor on linux and always elegant, cblizzard; the mozilla brazil driver mgalli; as well as the nice leoz, romaxa and timeless from the microb project.
  
• From prism (+maemo), I got a fast but good talk to mfinkle: the point was mainly pushing prism forward on maemo and linux, and make it a fennec friend on the platform.
• The new mozilla embedding system is not just promising but real.
  
• I met the famous Stuart ‘Pavlov’ Parmenter and got some nice advices about browser benchmarks, steps toward a rendering server firefox, as well as about some of the huge Javascripts speed up they are about to land in Firefox 3.1 (new JS is going +- 10x faster then the current) ...
  
• Percy and blassey are also nice guys.
• It is great to see fennec and microb joining efforts toward a great mobile user internet experience.

Some not accomplished things after the event:

• I wish I had met Daniel Glazman and John Resig.
• I wish to have had a shorter trip back: 7hs (from whistler to vancouver) + 5 hous waiting + 5 hous from vacouver to toronto + one hour waiting + 12 hours from toronto to são paulo + 12 hours waiting + 4 hours from sp to manaus = 46 !

Long life mozilla ...

--Antonio Gomes
tonikitoo at gmail dot com

Mozilla Prism for maemo

It sounds like another buzz-word candidate on the internet field is the term "RIA": many big guys commercially interested on RIA seem to concept it differently. My understanding about the term stands on its origin: RIA are applications running of top of browsers essential features and infrastructure: connectivity, interoperability, cloud storage (data available anywhere, any time), responsiveness, and so on, and IMO this is what drives the real meaning of RIA or "Rich Internet Applications".

PS: To avoid ambiguity we are generally referring RIA by "web applications".

In that sense, the Mozilla Prism project was launched w/ the intention of "integrate web applications with the desktop, allowing them to be launched from the desktop and configured independently of the default web browser". The project implements new concepts including "SSBs" and "distraction free browsers". Ok then, lets analyse what we have here from different perspectives:

1. On the pc (w/ satisfactory processing capabilities), users can have their web browser w/ many tabs opened, their RIAs living each one on their own process and windows, as well as many other OS applications all at the same time and their PC are able to run great.
   
2. But what about it all on the mobile space ? To be honest I am not really sure about the answer, *but* that is what this port job is mainly about: getting feedback about what maemo users get when they can somehow to integrate common WebApps (meebo.com, gmail, gdocs, gchat, ...) with their mobile desktop environment.
   

Although the TODO list is still big, the DONE list is accomplished so that it worth making "Prism to Maemo" project public.

1) Installation

While I am still having trouble to get my upload account to 'Maemo Extras" repository working fine, I've set up one living under my personal web dir: .install file here.

2) Warnings

• I will be working on this more seriously from now on with guys (luckily on #prism - irc.mozilla.org) to see what features are really interesting to have available on the mobile/maemo space.
  

• It is still an "under porting" work. so bugs are likely to be found and new releases are likely to appear.

• .deb sizes 10Mb and installed it takes 30Mb on disk.

Hope you enjoy.

--
Antonio Gomes
tonikitoo at gmail dot com

Prism + Webapps + Maemo = ?

Since a while I've being paying some attention into the promising Mozilla Prism project (old WebRunner), specially over a mobile developer perspective. Prism is a Mozilla Labs advanced development project that provides "a simple XULRunner based browser that hosts web applications without the normal web browser user interface". More interesting over is that the project came to me at the same time philip van hoof blogposted about "Web 2.0 email clients" (or something like this). My post could even get titled "mozilla-based web 2.0 email client" (or something like this), but Prism goes far away forward from that.

Main concepts here are two: Site Specific Browsers (SSB) and Distraction Free Browser:

• SSB: applications with an embedded browser designed to work exclusively with a single web application (whereas typical browser chrome are rarely used). It doesn’t have the menus, toolbars and accoutrements of a normal web browser . An SSB also has a tighter integration with the OS and desktop than a typical web application running through a web browser.

• Distraction free browsing: "This is nice for those times when your have to have your web based email and docs open but you don’t need the distraction of the rest of the Internet keeping you from your work. Plus the memory footprint is kept to a minimum because it isn’t the ‘full’ browser and all of its extensions."

Could that interest users of mobile devices ?

Not sure about the answer, but I put some effort on that these days to answer this question with some practical stuff. First, I got blassey's xulrunner armel build for maemo, checked out prism source from svn, pulled Firefox 3 pre beta 5 source base (to work as my mozilla build system), built them all together and after some hacks I got Prism running on maemo OS 2008 w/ some webapps (meebo and gmail for instance).

I will try to get some thumb enabled set UI for it, as well as making a .deb/.install available for Prism to see how things go from a mobile user perspective ...

PS: Prism has nothing to do with web application development, it's simply providing a more desktop-application-like interface for web applications. Mozilla claims: "Unlike Adobe AIR and Microsoft Silverlight, we're not building a proprietary platform to replace the web ... Prism isn't a new platform, it's simply the web platform integrated into the desktop experience. Web developers don't have to target it separately, because".

UPDATE: Greetings to MFinkle and other for all work on this.

UPDATE2: Here is Prism as a Firefox 3 addon.

--Antonio Gomes
tonikitoo at gmail dot com

RSS Feeding in MicroB

Feature's already implemented (and landed on microb svn).



--
Antonio Gomes
tonikitoo at gmail dot com

Fixed Greasemonkey (MicroB port) installation problem on Chinook

Greasemonkey webaddon port for MicroB is now installable on Chinook again. Some have reported installation problems on chinook due to a libhildonmime0 incompatibility problem, but it is just fixed.

Tested on both bora (n800) and chinook (n800 and n810).

Have a nice browsing.

Antonio Gomes
tonikitoo at gmail dot com

Major security update recommended to all Microb Adblock Plus port users

Wladimir Palant, the original Adblock and Adblock Plus Firefox web-addon developer, among other complainings, has pointed out an important security hole in initial version of the Adblock Plus Microb port :

"... So I downloaded this Adblock Plus version and soon it was obvious that it is inserting an Adblock Plus button into all web pages the user visits — using my favicon as the image on the button. Which makes me the lucky guy who can track every move MicroB users do on the Internet (at least if I decide to send HTTP headers preventing caching)."

Happily, Andre Pedralho quickly fixed this issue and uploaded the 0.0.2-1 version of Adblock Plus MicroB port in a few minutes. It is highly recommend for all Adblock Plus (maemo port) users to update their packages to the newest as soon as possible. For the other raised issues by Wladimir in the post entry, including changing the addon port name, we are investigation how much we've changed from the original source to take the proper action.

--Antonio Gomes
tonikitoo at gmail dot com