Like this <https://wiki.mozilla.org/User:David_Regev/Firefox_ZUI>? :)

Also, can you elaborate on the Inline Tab History part? I use Google Reader

What Google Reader changed from many older readers (including the first
version of Google Reader) was the move from displaying one news item at a
time to displaying a ‘river of news’. So, instead of replacing the entire
content area with each new item every time you want to read something else,
all items are displayed together one right after another. The big advantage
is that you can just scroll down to read new things, and going back is as
simply of scrolling up. So, what you’re viewing is no longer a single news
item but a river of news items. This can also be compared to Gmail’s
transition from single messages to conversations. We can do the same for
tabs: the tab no longer represents a single page, but a whole history of
related pages.

The other similarity to Google Reader is that each item has a border and a
header.

 Regarding the rest of your idea, I don't think I understand the advantage

Have you seen Ubiquity’s introductory
video<https://mozillalabs.com/blog/2008/08/introducing-ubiquity/>?
It’s very cool. But I’ll answer in more detail:

There are many reasons. This has been written about extensively elsewhere.
It all goes back to *The Humane Interface*, which ultimately led to
Ubiquity. Alex Faaborg wrong a great
piece<http://blog.mozilla.com/faaborg/2007/07/05/the-graphical-keyboard-use...>on
these types of interfaces a few years ago (pre-Ubiquity, I think). I
will
try to give a brief outline of the reasoning for this type of interface, but
I apologize if I fail to do it justice. It goes back to the advantages that
the command-line interface has over most graphical interfaces. For one, it’s
infinitely extensible: you can easily add a command without adding any
visual bloat whatsoever. With graphical interfaces, doing so would require
you to add yet another menu item or toolbar button or some other widget.
Secondly, it’s consistent. You issue commands by typing commands. With
graphical interfaces, you have to learn how to access each command: menu,
context menu, toolbar button, click, double-click, swipe, Ctrl-Alt-Shift-µ,
etc. It’s a lot to remember, and kind of a pain. On the other hand, command
lines have many problems, and I don’t think it’s necessary to list them
here. What Ubiquity does is attempt to carry over the advantages while
fixing the disadvantages. For one, instead of obscure commands, you get
natural language commands. The developers put a lot of effort into making
sure that you could use the most human-like sentences and it will guess
accurately what you mean. Secondly, it’s smart. Even if you type just a few
letters, it will suggest the most likely commands that you want to execute,
and learn which ones are most likely based on your behaviour. After a little
bit of training, you’ll be able to run many commands simply by typing just a
few characters, or even just one. Finally, Ubiquity introduces graphical
improvements that the traditional command line lacked, such as an
interactive preview.

You’ve undoubtedly seen interfaces like this before. Isn’t Google really a
textual command interface? People love using it because it’s so smart
(unlike the traditional command line), and so fast. Then there’s Firefox’s
“awesomebar”, which behaves much like the way I just described. It’s a
pleasure to use because it almost knows what I want, and it’s usually faster
than going through the Bookmarks or History menu, even though it’s less
graphical. The basic idea is that a good search implementation is usually
faster than browsing graphically. If you’ve ever used Windows’ search in the
Start Menu, or Quicksilver on the Mac, or GNOME Do, or other similar
interfaces, you know how much more pleasant it is to use these interfaces
over the ‘click, click, click’ way. And this is what Ubiquity tries to do
for the domain of commands.

But the most fundamental advantage to Ubiquity is that it’s ubiquitous
(hence the name). Normally, if you want to modify text in some way that only
your word processor does, you have to run that application (be it Word or
Google Docs) and use that function there. Commands are bound to
applications. So, each new application has to reinvent the wheel, and it
always has to be concerned with bloat. With Ubiquity, this craziness is not
necessary, since commands work everywhere (on the Web, that is). Instead of
running a word processor because you need, for example, to capitalize a
string of text, you install that command and can now run it anywhere.
There’s *a lot* of potential here.

 Also, will you need to use a command to copy and paste (the humane

If you copy and paste a lot, Ubiquity should learn what you want to do with
just one letter. In fact, if you select a piece of text, I think that just
bringing up Ubiquity should bring up suggestions for that context, with *copy
this* being one of them (and the top choice if you use that command a lot).
So, using those commands should be almost as fast for people who need them a
lot, but not as fast for people who use other commands more often.

Finally, how will you introduce users to features such as restore closed tab

Those can all be exposed as commands, combined with well-designed previews.
For closed tabs, something like a searchable Closed Tabs or a History area
in Panorama would be awesome. These types of things should be visualized
graphically when possible, since that allows us to display such information
in a richer way, which is currently not done. Panorama has quite a lot of
potential for that.