Firefox now only has one HTML parser
blog.mozilla.org
blog.mozilla.org
From a quick reading, it seems to be a mix of synchronous vs asynchronous parsing, historical reasons, and stuff. He identifies eight different behaviors.
I think it went a little over my head. What role does about:blank actually play? I'm assuming that the wild behaviour and parsing difficulty is the result of it performing some special function (beyond just returning a blank page).
Add various events (readystatechange, DOMContentLoaded, load) to added fun. And the fact that browsing contexts that are top-level from the Web perspective are iframe-like from the XUL perspective and the code for dealing with this duality is a mess.
1. Servo--http://www.webmonkey.com/2013/04/mozillas-servo/
2. or, Electrolysis--http://www.internetnews.com/blog/skerner/mozilla-set-to-revi...
Also see https://bugzilla.mozilla.org/show_bug.cgi?id=392073
In any case, Gecko is multiprocess already, and it's fully deployed on Firefox OS (and, as of recently, sandboxed). Firefox is not multiprocess because (generally) the front end has not yet been ported, and the project to do that is called Electrolysis.
Comments are important in non trivial applications. Please stop thinking they are not.
It's important to have both pieces of information in the same place, to minimize the overhead of fixing some subtlety someone might incidentally notice as a side effect of glancing at the code while working on related code.
I can't count the number of times I've run into a complex bit of poorly commented code that looked like it mishandled a subtle corner case, politely emailed the author(s) asking what the intended logic is before claiming I found a bug, gotten the "read the code, dude" response, come back to them with "is the intention really to <insert description of corner case behavior>", and gotten back "my bad, broseph".
There have also been a few times that I've incidentally noticed something looked like it didn't handle a corner case properly in poorly commented code (but not so wrong to obviously be a bug), but failed to follow up with the author due to time pressure on the things I was supposed to be working on, and later had that corner case behavior bite us.
"Why this way and not that way" is often important, and a comment to that effect can save future maintainers a lot of going down blind alleys.
Do you reuse code from Rhino? (Mozilla's Java based javascript engine)
Why not convert the code from Java to C++ once, and then maintain the C++ code?
The portable core of the HTML parser is maintained as Java. However, the translation is not done during the Firefox build process. Instead, the translation is triggered manually when the Java code changes and the output of the translation is committed to the Firefox source repository.
(The Java code is committed to the Firefox source repository, too, to make license compliance easier for downstream projects that opt to distribute the whole app under the GPL. The Java code is the preferred form for making modifications for GPL purposes.)
Edit: As for why not maintain C++ separately, that would mean doing maintenance twice: once for Java and once for C++. The parsing algorithm still changes from time to time. Support for the template element was added. Spec bugs related to how nested HTML inside SVG and MathML work were fixed. I expect a subtle spec change to how correctly deeply nested phrase-level formatting tags are handled in the future, since the part of the spec that handles misnesting breaks correct nesting. Oops. (But it's great that browser are now so spec-compliant that you can see that it's a spec bug, because Firefox, Chrome and IE10 all show the same weirdness.)
Was that the main reason to code it in Java?
Even though testing wasn't the original motivation for writing in Java, it's much nicer to unit test the parser as its isolated Java manifestation than as its Gecko-integrated C++ manifestation.
Or it will be so small that doesn't matter?
The biggest advantage was really just getting rid of a bunch of unused and unmaintained code.
This browser was great when it come out, fast, reliable and virus-free. I remember the good old time of IE when you have to wonder forever whenever if you'll click on a suspicious link or not. However, I have the feeling since chrome come out, they don't innovate anymore. Extensions are slow and unreliable, a lot of stuff feels like copy/paste from Opera or Chrome, Firebug, once the greatest, seems outdated, they have taken forever to support retina display on the mac, their engine crash or freeze in JS heavy environment... and they removed the blink tag.
My 5 cents.
Maybe I am wrong, but I keep using side by side with Chrome and Safari (Nerds has a lot of tabs and windows open!) and that's my feeling.
[1]: https://blog.mozilla.org/javascript/2013/07/18/clawing-our-w...
While I share some sentiments in regards to their UI, Mozilla has done nothing but good moves so far - supporting PDF.js, Shumway, Servo, Rust, Mozilla Persona (login), Jetpack, etc. Firefox has performed admirably and I use it as a main browser.
Am I missing something? Why is the one-process-per-tab model considered "severely" superior?
So FF devs, if you're listening, this is a vote against Electrolysis (if it means higher memory usage than current FF).
I'm not sure process-per-tab is "severely" better. However, how are you measuring that 1.6 GB? If you're not careful, you're N-counting the copy-on-write pages that the processes are sharing. Even chrome://memory-redirect has a note that Chrome itself has a bug with N-counting its RAM usage across tabs. (Issue 25454) The RAM overhead of process-per-tab is more than the fanbois will tell you, but it's much less than you see by adding up the sizes you seen in top/taskmgr, and is less than seen in chrome://memory-redirect.
Sandboxing for security and fault tolerance is a big deal; it's certainly worth the difficulty in figuring out how much RAM is actually being used by N tabs, if that's your main complaint.
Edit: I'm notorious for browsing with 30+ tabs open. I currently have 48 tabs open, and I'm not noticing any ill effects from high RAM usage. I really wish there were a keyboard shortcut for pushing the address of a link onto a temporary bookmarks stack, and another shortcut for popping a bookmark and opening a tab.
I use Firefox with tab groups and lazy tab loading and have probably over a thousand tabs in all the tab groups I use. This is very useful for me doing research and I haven't yet found a better workflow. I don't believe I would be able to achieve this with Chrome with any reasonable RAM usage.
> I really wish there were a keyboard shortcut for pushing the address of a link onto a temporary bookmarks stack, and another shortcut for popping a bookmark and opening a tab.
I use the Firefox addon "Save-to-Read" for this purpose and works great.
My macbook has 8 GB of RAM and my stationary has 12 GB so in my case the memory footprint is far less important than having tabs separated in processes.
----
edit, Many times I have to pause a download and then resume to get the dl unstuck.
But to be fair from both our ends, neither is that useful individual anecdote(s) != empiricism.
Yep. Luckily it’s being fixed as we speak: https://bugzilla.mozilla.org/show_bug.cgi?id=420355
I don't know if .crdownload has a header, but it doesn't seem to work the same way.
https://addons.mozilla.org/en-US/firefox/addon/restore-blink...
Disclaimer: I created the above extension