Chris Blizzard: upcoming mozilla toronto devday

David Humphrey has a post up about the upcoming Mozilla Toronto DevDay. It’s taking place on Monday Sept 15 and Tuesday Sept 16 and is worth checking out if you’re in the Toronto area.

Sean Alamares: The office

When you walk through the double-doors of the main building, the first thing you see is our tiny little lobby area. It’s so tiny, actually, that I think most people don’t even think it’s a lobby. It’s more a vestibule, I guess. Tinier than my bedroom. Tiny tiny tiny. And really underwhelming. It gives you very little clue as to what’s inside, and you could just as well be at a dentist’s office with how sparsely it’s decorated.

When you walk through the next door, though, the one which requires keycard access, life gets a lot better.

There’s a huge portion of the downstairs area devoted to a large screen and mounted projector. Encircling that is a crescent-shaped set of some very comfortable brown couches, with yet more comfortable couches behind them — one of which actually turns into a bed — and a giant table behind that. You know, for work. There’s a kitchen filled with free snacks and drinks, electric scooters to quickly travel between buildings, a pool table that’s been converted to a ping-pong table, and Nintendo Wii controllers scattered everywhere. There are Mozilla posters, and Firefox stickers, and awards we’ve won, and news articles about us decorating the walls. There are offices down there, too, but they seem almost like afterthoughts. The downstairs area is everything you imagine a dotcom workspace to be. A playground.

Upstairs, things get a little more serious. There are cubes, sure, but most of them are conjoined, and with the walls being so minimal and the ceiling being so high you never even feel like you’re in an office. Natural light permeates throughout the space — from the sun roof in the center, to the large windows all around the second story — and you could work most of a summer day without ever flipping a light switch on. Some people even got patio umbrellas for their desks for shade, they get so much sunlight. There are little, odd-shaped tables scattered about called collaboration stations, where people can sit together and bounce ideas off of each other, and office chairs which we have in about as many colors as we do configurations. There’s a kitchen up there, too, and if you look in the freezer you’ll probably find a couple different kinds of ice cream.

Across the complex is our other building, filled mostly with engineers. They have a kitchen, and scooters, and couches too, but it’s more quiet there. Disciplined even. I visit there every so often and the vibe is just so completely different. There are a lot of distractions in the main building, but in this one things are focused. They are serious cat, and that are serious thread. Still, I do enjoy my time there if only because I think the Building K (that’s the main building) people kind of take my being there for granted at this point, and the Building S people manage almost entirely without me, which is both refreshing and unsettling.

It makes me curious, though, about how the dynamic of the company might be if ever we were all under one roof. I should hope whatever brave new space we might someday end up in is as open, collaborative, and unique as the current one is. Because, really, at this point I couldn’t imagine anything less working for Mozilla.

David Humphrey: Mozilla Toronto DevDays and FSOSS

I’m back from a mostly offline summer, and it’s busy already!

First, we’re hosting Mozilla’s Toronto DeveloperDays on Monday Sept 15 and Tuesday Sept 16.  In the past Developer Days have often been a chance for existing Mozilla developers to have some face to face time, but not the right place to go if you’re new.  This event, especially the first day, is geared toward getting Mozilla into the hands of developers who aren’t currently targeting the platform or contributing.  If your company or project is writing web-aware software in some form, come and get connected, learn, and expand your options.  The second day will focus on testing, and is aimed at existing Mozilla developers.  But by the second day all first day attendees will be Mozilla developers :)  The event is free to all, food is provided, and fun is guaranteed.  Sign-up here.

Second, the Call for Proposals for the Free Software and Open Source Symposium (FSOSS) is still open, but going to close on Sept 12.  If you’ve been thinking of submitting something, please to it soon so you don’t miss the cut-off.  Also, general registartion will be opening in the next few weeks.  I’ll post with details when it does open.

Doug Warner: Speaking at CPOSC in October

I'll be speaking at CPOSC this October in Harrisburg, PA.  I will being giving a talk about Mozdev's architecture and history; about how it has grown over time from an all-volunteer effort to my current employment with Mozdev and where Mozdev is going.  I plan to go over some of the architectural changes that have come about through its lifetime and how we've tackled certain challenges.

Registration at CPOSC is limited to 100 people and seats are going quickly.  The conference is being held Sunday, October 19th in Harrisburg, PA; if you're interested in coming I'd recommend signing up soon!

Simon Paquet: Slides from my "Localizing Thunderbird 3" summit presentation I've finally managed to upload the (few) slides from my "Localizing Thunderbird 3" session from the mozilla summit.

Enjoy! [Source: Planet Mozilla]

Tristan Nitot: Mozilla's future: financial resources secured

Google

Mitchell's blog post about Mozilla's future has a very interesting tidbit that may go unnoticed. I'll post it here so it gets a little more attention:

We've just renewed our agreement with Google for an additional three years. This agreement now ends in November of 2011 rather than November of 2008, so we have stability in income.

The past deals with Google spanned periods of 2 years, so not only we have secured income with our biggest partner, but we have secured it for a longer period of time.

This, on top of ground-breaking recent announcements such as TraceMonkey, the concept series and Ubiquity — along with increased localization efficiency — demonstrate our ability to innovate and execute on a global scale. Combine this with a secured revenue stream, and we're ready to kick ass for the long term!

Smokey Ardisson: “Enlarge the content on this page” (or, “Zoom In”)

Wednesday afternoon I landed Christopher Henderson’s first Camino patch, which enabled Gecko 1.9’s content (or full page) zoom feature. Most people are familiar with our “Bigger Text” (and matching “Smaller Text”) function, which simply increases the size of text on a web page, often with disastrous consequences to “finely-tuned” site layouts. Content zoom, by contrast, scales the entire web page—text, images, layout quirks, and all—at the same time, producing text that is easier to read without also causing some of that text to disappear under other portions of the page or other disruptive layout changes. This new zoom will be in the 28 August Camino 2.0a1pre nightly.

Content zoom takes over the ⌘+ and ⌘- keyboard shortcuts from text size (those move ⌘⌥+ and ⌘⌥-) and as such becomes the “default zoom,” but both text size and content zoom are available in all three traditional methods of invocation: the menu (text size commands appear when ⌥ is held down), the keyboard, and on the toolbar (where text size and content zoom are both available as optional buttons).

We’re aware that there are compelling use-cases for both types of “zoom” and that replacing one with the other has caused some consternation in other browsers, which is why we’re happy to provide both at all times. We are seeking feedback about the menu and keyboard shortcut configurations, so please let us know what you think after you’ve played with the feature for a bit.

Special thanks to Eiichi for providing us with a MainMenu.nib saved on Mac OS X 10.4.11, and thanks again to Christopher Henderson for implementing the feature—we look forward to your next patch!

David Miller: What do you want to see while you wait?

On bugzilla.mozilla.org, when you run a search, if your browser supports “server push,” Bugzilla will show you an interim page while the search runs.  Currently it shows an animated dino head (left) chomping on bugs, and the text “Please wait while your bugs are munched retrieved.”  It’s cute and all, but it’s kind of getting old.  And being that the page is entirely a cosmetic thing designed to entertain you while you wait, we should change it out once in a while anyway.  We’re planning to upgrade Bugzilla tomorrow night, and it’s the perfect opportunity to spice it up a little.

Gerv’s got a few ideas over on bug 438362… a neat javascript backed game where you click on the ants or somesuch.  If you like it or think you’d hate it, comment here (go try the mockups on the bug first).

If you have other ideas, or can implement one of the existing ones, feel free to post them on the bug.  I have a couple ideas, but no artistic skills to implement them…

• A Mozilla dino standing there waiting for bugs - Buggie walks over to him carrying a basket of critters and hands it to him.
• Buggie standing there with his hand shielding his eyes from the sun, turning his head back and forth like he’s looking for something…

Maybe if we have several of these things, it could randomly pick one each time.

Buggie poses for you, courtesy of Dave Shea.

Planet Mozilla Blog: Planet Addition: Class of 8/27/2008

Tiffney Mortensen (feed) - Tiffney works most closely with Mitchell Baker, Harvey Anderson, and Dan Portillo on a variety of Executive, Legal, and Administrative projects. Her blog entries focus on the “big picture” of the Mozilla project as well as the social, cultural, and linguistic impact of the Web on our lives.

Sean Alamares (feed) - Sean is the desktop support engineer at Mozilla Corporation and will be writing about what life is like working at Mozilla.

Gen Kanai: Internet censorship in Malaysia

Colin Charles, LiewCF and Bernice Low of CNetAsia are all reporting that the Malaysian government is blocking Malaysia-today.net, which is currently accessible at http://mt.harapanmalaysia.com/2008/

Why is TM Net blocking access to Malaysia-Today? Answer: On MCMC orders.

3 Ways to Access Blocked “Malaysia Today”

Malaysia Today Mirror

ISPs ordered to cut access to Malaysia Today website
Practically speaking, censoring a website only brings attention to it, and if the content is available via other urls, then the censorship is next to worthless.
This does, however, bring a sober reminder that Malaysia may claim to provide a censorship-free Internet, in fact they do not.

Sean Alamares: Backstage

So, first things first, a little about what I do I guess.

The short of it is that I do desktop support here at Mozilla. All of it. Desktop support is an odd position because while the work invariably ends up being less technical than that of the other members in my department, I — and this isn’t immediately obvious — actually end up having a higher level of access than probably anyone else in the company. This includes my boss, his boss, all the way on up the chain. This is so, in part, because I actually have no-questions-asked physical access to everyone else’s computers, let alone the datacenter and all the requisite administration privileges of someone working in IT. That, along with the simple fact that my job requires I interface with literally everyone in the company, means I have a sort of backstage pass to all of Mozilla.

So, what does that mean? Well, I guess the hope there is that all this freedom makes me uniquely qualified to share a point of view with the world (or the PLANET. Ha!) at large, on Mozilla. One that’s both broadly sampled, and finely nuanced. A point of view that’s just about as close to the ground level as you can get.

The view from the bottom.

David Mandelin: Inline threading, TraceMonkey, etc.

It’s been a long time since I’ve posted here-I wanted to post some interesting results about speeding up SpiderMonkey using inline threading, but it turned out to be really hard and took a long time to get close enough to “interesting results”. At last, my patch is good enough to run SunSpider, and runs it 8% faster than baseline (non-tracing trunk SpiderMonkey from a few weeks ago), 10-20% faster on favorable benchmarks, and 48% faster on 3bit-bits-in-byte. So that’s pretty cool.

Of course, 8% looks pretty puny next to the huge gains of TraceMonkey (congrats to those guys, by the way). But I’m assured that interpreter speedups still count, so I’m chugging along. (Side note: inline threading speeds up SunSpider’s access-fannkuch benchmark by 22%, which has proved difficult to optimize with tracing.) (Side note 2: I’ve been told that TraceMonkey will hugely speed up our static analysis scripts, maybe 10x or so, which is great news.).

Insane, gory detail on inline threading, related optimizations, and detailed performance analyses can be found in bug 442379. I thought I’d go over the key ideas in this post:

Inline threading. Basically, this is yet another interpreter opcode dispatch technique. I previously wrote about opcode dispatch, concluding that direct-threading, in which the opcode is a target address, and the code to start the next op is a single indirect jump instruction is the ultimate efficient dispatch mechanism. It turns out I was wrong.

Inline threading is the “best”, because it gets dispatch down to 0 instructions. The idea is to create a buffer, and copy into it the native code for each opcode to be executed. For example, for a function body like “return a+3″, the opcodes are: JSOP_GETARG (0), JSOP_INT8 (3), JSOP_ADD, JSOP_RETURN. To inline thread this, we create a buffer and fill it with native code like this, using memcpy:

code for JSOP_GETARG
code for JSOP_INT8
code for JSOP_ADD
code for JSOP_RETURN

It’s like a really crude form of JIT compilation.

To run the function, we just jump to the start of the buffer, and then it all runs, with no further dispatch code. I’ve found that an average SpiderMonkey op executes about 35 instructions, so inline threading removes the 4 instructions for indirect threading, reducing this to 31, and should speed up SM by about 11%. Nice!

For more info on inline threading, see SableVM and this paper.

Hard Stuff. The only problem is that what I just described doesn’t actually work. For one, the compiler doesn’t necessarily compile each SpiderMonkey op handler into a single block of code. In fact, it usually reorders things a bunch, to help with code locality and reduce the number of jump/branch instructions executed on hot paths. So those are too hard to inline. (It could be done by disassembling parts of SpiderMonkey, analyzing the results, and doing code layout again, but that’s a bit much.)

Also, because most jump, branch, and call instructions express their targets using a relative address (an offset from the IP of the following instruction), any jump outside our little inline-threaded buffer becomes a jump to hell. So those would all have to be identified and patched, again with a dissassembler.

In general, small ops that don’t call functions, generate errors, or have much internal control flow can be inlined, but everything else can’t. Fortunately, “small ops” include some really common ones like JSOP_GETVAR and JSOP_POP, but the technique can’t be used without some special treatment for the big ops.

Call Threading/Context Threading. For big ops, I used something called call threading or context threading. Call threading has been used to produce big speedups on some interpreters, but turns out not to help at all for SpiderMonkey. But it can handle big ops in an inline-threading system, and after a lot of work, I at least got it to not slow down SpiderMonkey.

The idea of call threading is to create a native buffer, but fill it with calls to the opcode handlers instead of copying the whole handlers in. With the previous example, it gives you:

call &JSOP_GETARG
call &JSOP_INT8
call &JSOP_ADD
call &JSOP_RETURN

Those are x86 call instructions. For this to work, the opcode handlers have to end with ‘ret’ instructions. This means dispatch is 2 instructions, which is better than indirect threading’s 4, and I think better even than direct threading because that’s really 3 instructions if you count getting the op, which I should have before. Also, these call and ret instructions are highly predictable (99.9%+ prediction rate), unlike the indirect jumps used by direct and indirect threading, which are very unpredictable. Since a mispredict is very costly (~16 cycles on Core 2, I think), this gives a big speedup, 30% or so on some interpreters.

Except on SpiderMonkey, where unfortunately it doesn’t work and also slows things down. This was very frustrating.

The reason it doesn’t work is that when you execute a ‘call’ instruction, you push the return address onto the stack, decrementing the stack pointer ($esp) by 4. The opcode handler will then crash if it calls a function. There are actually several reasons why but the most important is that on most systems, the stack pointer has to be 16-byte-aligned when you call a function, and that -4 puts it off.

To make it work, I add extra code to unpush the return address right after the call, and then unpop it back right before the return. This works, but now we’re up to 4 instructions, so we haven’t saved any instructions over indirect threading. (I would love a better solution, but I couldn’t think of one.)

Next, it turns out that in SpiderMonkey, due to clever optimization by Igor & Co., the branch prediction rate is already excellent in practice: 80-100% on benchmarky-type programs. (The trick is make sure there is a separate indirect jump going out of the end of each opcode, so the processor can predict each one independently. Also, the Core 2 indirect branch predictor seems very smart.) So branch mispredicts are only costing an average 0-3 cycles per op. SpiderMonkey takes about 28 cycles per op, so this gives an estimated speedup of 0-12%.

Last, the really tragic thing is that the changes I made to make SpiderMonkey do call threading make GCC shoot itself in the face. For reasons I don’t entirely understand, GCC compiles the op handlers “differently”, so they run at least 5% slower. It took some doing to figure out how to keep the slowdown down to 5%, which makes call threading about even with indirect threading. That’s pretty disappointing, but at least it means I can call thread the big ops without penalty (on average), and then inline the small ops, getting some speedup. With the example code, I generate:

code for JSOP_GETARG
code for JSOP_INT8
call &JSOP_ADD
call &JSOP_RETURN

(The optimizer issue is incredibly arcane, but I think I traced the problem to an optimization pass called “gcse2-post-reload”, which is really partially-redundant-load elimination after register allocation. Any kind of partial redundancy elimination (PRE) can slow code down. The slowdown effect should be mitigated when using profile-guided optimization (PGO), but I couldn’t get GCC PGO to work on SpiderMonkey to test that theory.)

For more on call threading, see this paper, keeping in mind that the results would probably differ on Core 2 because of its presumed better indirect branch predictor.

Inlining-enabled optimizations. Inline threading some stuff and call threading the rest doesn’t yield exciting gains for SpiderMonkey, maybe 2% overall and 5-20% on the “good” benchmarks. (I guess that’s not too bad, the 2% overall just seems really weak.) But inline threading enables a bunch of other cool optimizations that could speed things up more. I’ve only done the easy ones so far, and that got the 48% speedup on 3bit.

Easy optimization #1 is to stop updating the SpiderMonkey PC. The call and inline threaded code tells what op handler to run next, so the PC is unnecessary. Actually, some ops do use the PC, and I’d like to make them not do that someday, but in the meantime I can just generate code to set the PC in my native code buffer:

mov 0, [pc]
code for JSOP_GETARG
mov 2, [pc]
code for JSOP_INT8
call &JSOP_ADD
mov 5, [pc]
call &JSOP_RETURN

It looks like I only saved the PC update for JSOP_ADD, but it’s better than that because the standard code has to load the PC, increment it, and then store it back, which I’ve replaced with just one instruction. The PC optimization is relatively easy and saves 0-3 instructions per op, which means a 0-10% speedup by itself. And it actually works.

“Easy” optimization #2 is to specialize certain opcodes. Take JSOP_INT8 as an example. This op pushes an integer onto the interpreter stack. That’s 3 or 4 instructions, to manipulate the stack pointer and store a value to it. But it also has to get the value out of the opcode stream and convert it to a jsval (the tagged value type of the interpreter), so it’s actually 9 instructions. (And JSOP_INT32 is much worse because it has to fetch 4 bytes from the opcode stream and shift and or them together.) But if we’re inlining JSOP_INT8, we can just inline the 3 or 4 instructions using the actual value, a version of JSOP_INT8 “specialized” for the given value. I do the specialization by writing the op in assembly code with a dummy value (0xdeadbeef), finding the location of the dummy as part of interpreter startup, and then patching that location as I inline. This seems crazy, but all the other design options seem crazy in their own ways, so I went with it for now. With specialization in play, the example looks like this:

code for JSOP_GETARG specialized for slot 0
code for JSOP_INT8 specalized for jsval for 3
call &JSOP_ADD
mov 5, [pc]
call &JSOP_RETURN

Because JSOP_GETARG and JSOP_INT8 use the PC only to get their arguments, which specialization bakes in, we get to remove some more PC updates too.

Compiler nitpickery. In itself, all this stuff works, and it’s been used in various research projects before, and probably some other interpreters by now. But this particular implementation of it depends a fair amount on what the compiler does: at least (a) that the compiler doesn’t reorder small ops too insanely, (b) that you can take the address of labels (to get the start and end of op handlers), (c) patching in some ‘ret’ instructions at runtime (needed to solve an obscure problem I didn’t feel like discussing here), and (d) that the compiler doesn’t deoptimize too badly when you do all this. That seems possible, but it’s not clear yet that this will play well across different versions of GCC and ICC. (Crazy side note: in my tests, GCC 4.2 on Mac regresses SpiderMonkey SunSpider by 5% vs. GCC 4.0.)

The Mozilla Blog: From Firefox user to Extend Firefox contest winner!

Editor’s Note: Today we bring you a guest post from Felipe Gomes of Brazil, a winner of the Extend Firefox 3 contest.  Felipe is a newer, but very active Mozilla contributor. We asked him to share how he came to be involved with Mozilla.  Congrats again and thanks for all of your hard work, Felipe!

Hi all!  I’m Felipe Gomes, a computer science student from Brazil. As a geek, I’ve always appreciated and believed in open-source, and have tried to get more involved since going to college.  I began using Firefox add-ons when I started with web development, and that led me to learn more about the technologies behind Firefox and its platform. I learned XUL and JavaScript by reading, practicing and trying to run random ideas and experiments in the browser.

I had been following the Mozilla project for a while, but discovered how fruitful it is to be an active member earlier this year when I joined the Brazilian community.  I discovered that there are many passionate members all over the world who love Firefox and want to promote the culture and the browser, regardless of their city or country.  I’ve had the opportunity to interact with many community members this year when I gave talks about XUL and add-ons development.

It’s been very fun and rewarding to be involved.  During the frenzy of the Firefox 3 launch, I created a Download Day Countdown add-on, helped spread the World Record in Brazil and organize our local launch party! I also had the opportunity to work on the programming side, when I did some Processing.js demos and, more recently, submitted an add-on to the Extend Firefox contest.

I got involved with the Extend Firefox contest because when the betas came out it was clear that the browser was growing to a whole new level. There was just so much potential to explore in basically every aspect of the browser. And the Extend Firefox 3 contest was the perfect fit, encouraging developers to leverage the new potential that Firefox 3 brings.

To be one of the contest winners was a very special moment for me, and an honor, especially because of the number of great extensions that were submitted and chosen (I’m already using many of them!). The great responses, comments and suggestions that people have been sending in the last week made me realize that when you have an idea that you believe in, you really should work on it. Turns out, other people might like it and believe in your idea as much as as you do!

I’d like to thank all the nice people I got in touch with this year in Mozilla Brazil and the greater community: Marcio, Mario, Clauber, Fernando, Andrea, Mary and Chris. And congratulations to every developer who joined the contest! Let’s keep spreading the love for Firefox!

Eric Shepherd: MDC tweaking continues

The last round of site changes went up last night, and today I’ve committed another, smaller change that will fix some legibility problems with code and other monospace text blocks. You can watch for when that change goes live by watching bug 452515.

It’s been pointed out to me that links to downloadable code samples are generally broken. I’ve filed a bug with IT to get that looked into; my guess is a rewrite rule needs to be added to the server to fix it, but I’m not certain. I’ll let the server gurus figure that one out.

I know some folks are still dissatisfied with the new skin. Complaints range from “I wish it were sans-serif” to “I don’t like drop-down menus, give me back the sidebar” to “ugh I hate it and I hate you for foisting this on me.”

Let’s take a look at these.

The sans-serif thing was a conscious decision. By using a serif font for the body text of the articles, and monospace fonts for code, variables, and so forth, the code bits stand out better from the body text. This is something that some people feel very passionate about, one way or the other, however, this isn’t something that’s likely to be changed soon (we have bigger fish to fry). If people still hate it in a couple of months, then we’ll look at it again.

I recognize the complaints about the drop-down menus as valid, at least to an extent. I actually prefer a sidebar or other always-visible interface myself when editing a wiki. However, after lengthy discussions with a lot of people before the skinn design started, we all agreed to go with the drop-down menus for one simple reason: to maximize the amount of actual content that the reader can view at once. Our goal is to present information cleanly and conveniently, and having a lot of “stuff” in the window doesn’t really achieve that goal.

That having been said, I still see validity in this complaint, especially for people who spend most of their time editing rather than reading the content, and it’s something I’m going to look at in the future, once other stuff has settled down. Hopefully sooner rather than later. I’m not going to promise anything — neither what exactly we’ll do nor when it will be done — but I will say that I intend to find a solution.

The last point I’d like to make is this: We put the new skin out there through several revisions starting in April. First with mockups, then with screenshots, and then, finally, an actual testable site for people to play with. I only got a handful of complaints during that time. It would have been much more helpful to have gotten some of the very good feedback I’m getting now back when it would have been easier to do something about it.

I know folks are busy, and a lot of people were very preoccupied with Firefox 3 at the time, but I’ve seen several comments from people basically saying that I drove this design through without consulting anyone, and am unwilling to take suggestions, and I feel compelled to point out I made every effort to ensure that everyone had ample opportunity to have their say and to help guide the design.

Anyway, having said that, I do want to continue to collect suggestions and requests, and we’ll see what we can do with them!

Madhava Enros: Decisions, decisions

Firefox has a lot of preferences. For illustration, here's a map of all of them that are accessible from the Preferences (Mac) or Options (Windows) windows:

Click for the readable version (large!)

That's seven tabs, one of which contains four sub-tabs (Advanced), over the course of which the user can click on buttons to bring up a further 23 windows or panels, one of which has a further five tabs. That's leaving out the Add-ons Manager, host to preferences for add-ons, and the monster-filled fathoms-deep sea that is about:config.

It's hard to get rid of preferences. Typically, there aren't any that are entirely without worth, and, on an individual pref-by-pref basis, it's hard to argue that removing functionality is worth the small ease-of-use gain of one less item. Over time, though, you're left with a situation that is the opposite of simple.

This is a problem to chip away at in Firefox; for Fennec, it demands immediate attention. The smaller screen on a mobile device and the button-density dictated by the size of a fingertip make it impractical to show a huge number of preferences — assuming that you'd even want to inherit that problem! Another defining characteristic of mobile is that the ratio of power-users to non- is skewed even further to non-power-users than on the desktop. Mobile users are just less likely to want to "configure" their mobile browsers.

For comparison, here's the full set of "Settings" in mobile Safari:

• General
  • Search Engine - Google/Yahoo
• Security
  • JavaScript - ON/OFF
  • Plug-Ins - ON/OFF
  • Block Pop-ups - ON/OFF
  • Accept Cookies - Never/From Visited/Always
  • Databases - lets you see a list and delete>
• Clear History (button)
• Clear Cookies (button)
• Clear Cache (button)
• Developer
  • Debug Console - ON/OFF

What preferences do you think are absolutely necessary in a mobile browser?

More News