mikeratcliffe

Fonts can be rendered completely differently on different operating systems, which often results in a different line height.

Controls such as buttons can also be rendered differently on different operating systems, particularly the border-radius and padding.

So if you don't test on each OS your page could look quite different on one OS when compared to the other.

Firefox 'cos it's awesome!

"Until that number changes I'm not switching to back to Firefox."

Maybe you should switch then, why?

A lot of this information is subject to interpretation.

# of Vulnerabilities in 2014: Chrome: 127 Firefox: 108

The code exploit stats show how many exploits were found and patched, which is completely different from the number of exploits that a browser has.

Only 4 exploits were found and fixed in Chrome whilst 55 were found and fixed in Firefox... in my opinion that makes Firefox the leader as they found and fixed more vulnerabilities.

Firefox uses compartments per domain instead, which is a great alternative to process per tab: "Some readers might wonder how compartments compare to per-tab processes as they are used by Google Chrome and Internet Explorer.

Compartments are similar in many ways, but also very different. Both processes and compartments shield JavaScript objects against each other.

The most important distinction is that processes offer a stronger separation enforced by the processor hardware, while compartments offer a pure software guarantee. However, on the upside compartments allow much more efficient cross compartment communication that processes code.

With compartments cross origin websites can still communicate with each other with a small overhead (governed by certain cross origin access policy), while with processes cross-process JavaScript object access is either impossible or extremely expensive.

In a modern browser you will likely see both forms of separation being applied. Two web sites that never have to talk to each other can live in separate processes, while cross origin websites that do want to communicate can use compartments to enhance security and performance."

You can read more about how that works at http://andreasgal.com/2010/10/13/compartments/

you can always go to about:support and click "Reset profile..."

hehe... read the add-on comments.

Steve, the browser debugger should work with all extensions... what isn't working for you?

So, you are frustrated because:

1. Mozilla are improving the extension architecture and developer tools too quickly for you to keep up with and that leads to lots of documentation.

2. Because Mozilla don't want people to use their extensions to sell a users information, spy on them, advertise to them etc. the review process takes longer than Google's.

So you want something more like this? http://i.imgur.com/MCKla78.png

We have it working and will be adding it very soon. It will also be very easy for library authors to add their own event parsers to our tools.

Our devtools have unit tests that run for every tiny change that is made to Firefox. Building the tools in gives much more stability. We are also using and exposing a lot of low level Firefox stuff and fixing bugs as a result.

So in short you get a better, more extensible browser, more stability and the chance to take a look at how something you use every day works.

It's a win-win in my opinion.

If it was an extension we would lose stability because our devtools have unit tests that test against every Firefox change.

Firefox is faster these days. If you find it slower then you probably have addons that are slowing things down.

Try disabling your addons and enable them one by one to find the culprit.

We implemented it that way so that we wouldn't have a never ending list of "the browser is slow when devtools are open" bugs.

We do plan on making the disable cache toggle more visible (probably with the other buttons at the top of the main panel) and making it very obvious that the cache is disabled.

When we have done that it would make sense to have the button remember state.

Can you try running in Firefox's safe mode and let us know if you have the same issue... sound to me like one of your extensions is leaking.

Regarding point #2: URLs will soon be clickable in the markup, rule and computed views.

Disabling the cache for a single tab still does not work. Maybe somebody could find a way to workaround this though.

We just don't want to disable the cache globally as this could cause issues in other windows.

This is a great place to start: http://www.mozilla.org/contribute/

Inlining all of your images as data URIs in your CSS is not a good idea because it will block the rest of the stylesheet from loading whilst images will not.

Yes, we also have plans for HTML editing that I think everybody will be very pleased with.

We have a bunch of Object Inspector requests and we will get onto them when we get chance: https://bugzilla.mozilla.org/buglist.cgi?component=Developer...

We are working on that. We also plan on adding multi-highlight for when e.g. you are in a selector in the style editor and a bunch of other goodies.

I think it is mostly that devs often don't have an online presence. Building your online presence and contributing to open source projects really helps recruiters see what you are capable of in the real worl.