Re: Mozilla approves a Tab Hiding API
- Date: Fri, 4 Aug 2017 11:47:49 -0700
- From: Mark12547 <firstname.lastname@example.org>
- Subject: Re: Mozilla approves a Tab Hiding API
In article <A8adnTXoaPBwhBnEnZ2dnUU7-I_NnZ2d@xxxxxxxxxxx>,
> I saw a very long article on Firefox 57, and it sounds like the ONLY
> thing positive is that it will be faster.
Not the only thing, but, yes, there is a big push at this time to
For example, about three months ago the Release version of Firefox would
take a bit over a minute to load my overly-long Netflix DVD queue and
all of Firefox would be frozen until the page finished loading. This
morning I just timed it at 39 seconds using Nightly 57.0a1 (2017-08-04)
(64-bit) to load roughly the same size Netflix DVD queue, and I had a
YouTube video playing at the same time and it continued playing without
missing a beat.
Performance also means rendering speed so videos, for example, can play
at a higher frame rate.
57 includes other improvements such as moving more tasks off the main
thread, reducing jank (the stutters in the user interface), as well as
improve scrolling and what they say will be "silky smooth browsing".
Firefox is also redesigning Firefox to make better use of modern
processors. First step was Electrolysis (a.k.a., e10s), which separated
out the content process from the main/UI process. (Actually, if one
considers Flash, Firefox has been using multiple processes in a limited
fashion for some time: to "sandbox" Flash into a separate process.) More
recently Firefox has been using multiple content processes (e10s-multi),
which allows me to load my Netflix DVD queue while still watching a
YouTube video. Actually, I can be loading my DVD queue, the Netflix DVD
home page, my Instant queue (which Netflix calls "My List"),
Titantv.com, and IMDB while a YouTube video doesn't miss a beat, all
because I have enabled the use of 10 content processes and they can make
good use of my 4-core CPU.
Mozilla programmers have even more performance changes they are working
on, some of which will land later in Nightly 57. (Right now Nightly 57
is mostly 56 with just a couple of changes, but most of the 57 features
will be added in the next few weeks.) There will also be an increase of
parallelism within a content process, and some of this will land beyond
There are plans to make more use of the gpu when it makes sense. A good
chunk of a modern PC CPU is the gpu, which the game writers have been
using, but has been used by browser writers only to a limited degree.
The User Interface changes were mentioned by WaltS48 and the reference
to the photon engineering newsletter. Many of the icons (extension
icons, pocket, print, download, etc.) can be moved into an "overflow"
menu or removed, or other functions can be moved into the icon area next
to the address bar or into the overflow menu as simply as going into
hamburger menu -> customize..., and dragging various elements on or off
the menu area.
Mozilla is working on improving reliability of Firefox by:
1. Changing the way extensions interact with Firefox to where extensions
interact with defined APIs instead of using overlays and directly
accessing the internals of the browser. By doing this, Firefox can go
through more internal changes and, as long as Mozilla maintains the new
set of APIs, the extensions that use these new WebExtensions APIs won't
break Firefox and Firefox won't break these new extensions.
2. The use of "sandboxing" extensions. A number of extensions will run
either in the content process or will (possibly as early as in 57) run
in a separate process so that an extension with an issue (such as wild
memory pointers or a get memory loop) won't bring down the main process.
Also, not only will extensions have to use the APIs' way of interacting
with the system, the process they run in can have restrictions on what
the process itself can do, so hidden code wouldn't be able to tamper
with the system.
3. The use of multiple content processes means that if one content
process crashes (and I have come across an occasional page that loves to
load pictures as one scrolls down, and that page seemed to be infinitely
long), the other content processes will continue to work, as well as the
main/UI process. And since the main/UI process is isolated from the
crashed content process, it can do a better job of diagnostics and
4. Rewrite of sections of the code in Rust, a language specifically
designed to be multithread-friendly. Eventually, for example, if
multiple tabs are using the same content process, and rendering in one
tab or even in one frame of one tab crashes, the other tabs using that
same content process or other frames in the tab that had a frame crash
would continue working. (One information video, for example, mentioned
that advertising often accounts for crashes, and having an advertisement
in a frame crash the frame but allowing the other frames on that page to
continue render would allow that page to render and be useful, though
without that particular advertising frame.)
There is also work to keep memory usage reasonable. Each process has
memory overhead, so being able to share more memory between processes,
or being able to set the limit on the number of content processes (in 57
this is through the Options menu for setting between 1 and 7 maximum
content processes, though additional processes can be specified in
about:config by altering dom.ipc.processCount), and more tabs than
content processes just means that multiple tabs will be rendered by a
content process. (If the default of 4 content processes are used and 8
tabs are open, each content process will be handling two tabs. Up side
is saving the memory for more distinct content processes, the down side
is that if one tab hits a situation that crashes the content process,
both tabs rendered by that content process will crash.) Contrast that to
Google Chrome, which on most systems will limit the number of content
processes to 20 instead of allowing the user, if the user so chooses, to
specify the number of content processes.
> No ad blocking,
There is something to be said about letting the Firefox developers
concentrate on what they do best, and let the ad blocker writers
concentrate on what they do best, and avoid a potential conflict of
interest between the browser's money stream (search engine agreements)
and the user's desire for no advertising.
Google plans to incorporate ad blocking in Chrome, but not block so-
called non-obtrusive ads.
AdBlock Plus allows a subset of non-obtrusive ads but has a user option
to block even those.
Both uBlock Origin (what I currently use) and AdBlock Plus do very good
jobs of blocking advertising. Neither require payment to use and neither
has any features that are enabled when one contributes. Both are working
on having WebExtensions versions of their extensions for when 57 rolls
into Release. (uBlock Origin currently has a beta that I am using in
Firefox Nightly 57.0a1 that has a thin legacy wrapper over the
WebExtensions code and tentatively plans to have a full WebExtensions-
only beta version in about three weeks. I don't know AdBlock Plus's time
table, but I know that they have decided at this time to port the
Chrome's version over and then add features to make the Firefox
WebExtensions version better for list developers than the Chrome
It takes far less work on Mozilla's side to get the WebExtensions APIs
up and working so these ad blockers will work efficiently than it would
take for Mozilla's programmers to design a new ad blocker from the
Also, if you know how to use uBlock Origin in Firefox, you know most of
what you need to use it in Chrome. And if you know how to use AdBlock
Plus in Firefox, you know most of what you need to use it in Chrome. So,
for those who end up using multiple browsers, having areas of
commonality between browsers (such as how to whitelist pages or
whitelist sites) reduce the learning curve. But if Firefox wrote a new
ad blocker and incorporated it in Firefox core, it would have its way of
whitelisting pages or sites that would likely not transfer to other
browsers and may change between releases.
> no extensions
That may be a bit of an over-simplification.
A number of extensions have been rewritten to use WebExtensions. Some
will soon be rewritten for WebExtensions but are waiting for needed APIs
to be implemented. (Some APIs may be after 57, say in 58 or 59 when 57
is finally released.) And some extensions, such as session managers and
those that change the UI design of Firefox, probably won't make it or be
a shadow of their former selves.
For example, four pure WebExtensions extensions I am using right now
Gecko Profiler: used when reporting performance issues. (I used this and
the Firefox developers were able to cut the time it takes for Firefox to
load my overly-long DVD queue.) Ok, this is one of those things more for
Hostname in title: this puts the site name (the www.reddit.com, for
example) in the Windows Title for a tab that is in focus. This allows
KeePass (and other password managers that look at the windows title) to
use the host name to match the saved useranem/password records with the
Tab Center Redux: this displays the tabs as a list on the left side of
the browser (or not, by hiding the sidebar).It can be handy when many
tabs are open and the tab list across the top is shrunk or scrolled off.
Bookmarks Organizer: a bit of a misnomer, since this extension can find
several issues but generally will search one issue at a time: broken
(the bookmark doesn't reach a page), duplicates (the same address
appears in more than one bookmark, which I do on purpose, but only for a
selected few), and missing bookmark names. It also detects page
redirects. While it isn't best for automatic fixes (some have complained
that if a duplicate is found, it will delete both bookmarks, when one
typically wants only one of the two bookmarks with the same address
deleted), but for a manual clean-up of bookmarks, this extension is
I use two extensions that are currently labeled "legacy":
uBlock Origin: I mentioned this above. It is a blocker that I use as an
ad blocker, currently the beta is a thin legacy wrapper over mostly
WebExtensions code, and is expected to be WebExtensions-only in three
SixOrNot: displays the protocol (IPv4 vs. IPv6) used on the page.
Clicking on the icon displays all the servers accessed by the current
page and their protocol (6 or 4) and IP address. It can be a surprise to
see a page delivered by IPv6 but most of its content is coming from
IPv4-only servers. There are other extensions that do similar things,
but a couple weeks ago when I looked for a WebExtensions flavor, none
were available at that time. There are several similar extensions in
Chrome that could potentially be ported over to Firefox, such as IPvFoo.
> no customization of the interface.
Limited. Thin themes will work, but not full themes. Moving or hiding UI
elements will likely, on the mostpart, not make it, at least not in
themes and extensions, though the Hamburger menu -> Customize does give
a number of options on elements on screen, overflow menu, or suppressed.
Classic Theme Restorer, for example, will not make it because Mozilla
has decided that the WebExtensions API will not do major UI changes, so
a potential WebExtensions flavor of CTR would be a shadow of its current
(legacy) version and the author of CTR does not want to release an
upgrade that takes away most of what it does.
Tabs hiding will likely make it so something like Tab Center Redux can
display tabs on the sidebar without having them also listed across the
top of the browser.
> Guess it is time to bite the bullet and get used to Google knowing
> my every move.
Google Chrome can be downloaded at
You can give it a try, search for extensions, themes, and see how it
compares to Firefox for performance and memory footprint. See if it will
give the customization, themes, and extensions that aren't already
expected to appear by the time Firefox 57 goes on the Release channel.
And see if you can find more than just a tidbit of Google's future plans
> mention of fixing things that REALLY ANNOY ME, like websites that stack
> an extra entry in the 'last site' list so you can't get off their page
> with the back button,
Those are annoying. Maybe that is why I got used to using "open in new
tab" when following links (Ctrl+Left+Click, or Right+Click, "open link
in new tab", or center button(wheel) click).
I don't know if Chrome does this better than how Firefox doesn't.
> and nothing about fixing the problems with videos
> not playing, or playing jerky on a 65mbps down cable connection, where
> Chrome plays fine.
That's a work in progress.
> When the extensions are gone, so am I.
There are likely to be more WebExtensions extensions available when 57
goes on the Release Channel; right now it is still a bit premature.
Also, some Chrome extension authors may decide to port some of their
extensions to Firefox since the Firefox WebExtensions are designed to be
similar enough to Chrome's extension APIs that ports from one to the
other should be relatively easy. (I see claims from some Firefox
evangelists saying that all Chrome extensions will work in Firefox as
is, but I don't see language that extreme in postings and blogs
purporting to be representing Mozilla.)
More WebExtensions APIs will also be added later once 57 is out the door
so some extensions may become available at a later date.
And, planned for about two weeks before Firefox 57 is placed on the
Release Channel, AMO (addons.mozilla.org, where we go to search for
extensions) there is a redesign planned so that when one searches on a
legacy extension it will also suggest WebExtensions extensions that may
be a replacement for the legacy extension. (Candidate replacements are
already being gathered as per https://discourse.mozilla.org/t/favorite-
webextensions/17087 and, unfortunately, this is a manual process.)
But, yes, many extensions will be going away. We are still 102 days away
from when Firefox 57 rolls into the Release Channel, and a lot can
happen in 102 days. Consider the possibility that it may be a bit
premature to jump ship. :)
general mailing list