It's pretty hard to get the code right in this autoconfig script, as the
only feedback you get is whether the script crashed or not. Add a
logging function to make it easier.
With the current implementation, `userChrome.css` and `userContent.css`
are effectively replaced on a package update, but the session still uses
the previous version.
Triggering a restart as soone as those files are updated ensures the
latest version will be used immediately.
The protection, identity, permissions and widget overflow popups were
flickering when their width was larger than the screen. This patch
bounds the width of the viewport.
It also makes the overflow menu use as much vertical real estate as
possible, as this seems to fix flickers for extensions.
Make sure the menu that gets opened when long-pressing the back button
is visible on screen. Note that this is useful not only for navigating
back, but can be used to navigate forward too, and to navigate back to
the new tab/home page.
Always reserver the space for the private browsing indicator, even if
not in private mode. This allows using the same width for the displayed
tab in both modes. Without this, the X of the tab is not visible in
private mode.
I think it's nice to have this space in both modes to quickly close the
menu, as it's right above the menu button.
This one is for being connected with the debugger. It's hard to edit the
CSS to make the urlbar look good with the debugger, if being connected
with it gives it another apperance. I'm currently fixing up the padding
to the left where the icon is, so disable it.
Now that there's a nice about:home page, show it in new tabs too instead
of the weird looking blank page. Set this in autoconfig.js instead of
policies.json, so it can be overridden by the user via settings page.
Disable everything but the search bar. This gives a clean page, of a
cog wheel on the top right where the user can adjust it as they want
(e.g. enable most frequently visited pages), then the FF logo and the
search bar.
I've considered enabling TopSites in order to show the most frequently
visited sites according to the browser's history. However, this also
enables built-in links to youtube, facebook, reddit, amazon, twitter.
And while it is convenient to have links you frequently visit available
(based on your history, not these built-ins!), getting an almost blank
page instead is actually a good idea to reduce the bad pattern of
opening a web browser and then forgetting your original intention until
it opens, and instead surfing mindlessly on the most recently visited
websites. The almost blank page gives the user a moment to think about
what they really want to do.
Here's something controversial. Install the wide-spectrum blocker uBlock
origin by default. This enables blocking of ads, trackers and malware
sites. I think these should be blocked for several reasons:
1. Performance on mobile devices
It's clear when browsing the web with this add-on, that there is a major
performance benefit in blocking advertising and tracking on websites. We
don't have these resources to waste on Mobile Linux.
2. Privacy
From uBlock origin's README.md:
> [...] it's important to note that using a blocker is NOT theft. Don't fall
> for this creepy idea. The ultimate logical consequence of blocking = theft
> is the criminalisation of the inalienable right to privacy.
> Ads, "unintrusive" or not, are just the visible portions of privacy-invading
> apparatus entering your browser when you visit most sites nowadays. uBlock
> Origin's main goal is to help users neutralize such privacy-invading
> apparatus — in a way that welcomes those users who don't wish to use more
> technical, involved means (such as uMatrix).
3. Manipulation
Modern advertising platforms are used to manipulate people in the scale
of influencing elections of world leaders. From Cambridge Analytica and
similar companies' perspective, one of the workflows is showing the user
an advertisement, then monitoring search queries to determine if the ad
was effective, then adjusting the ad to convince you better to vote for
a certain party, repeat. This has severe negative effects on society,
for people unfamiliar with the topic I recommend watching the movies
"The Great Hack" and "The Social Dilemma". The mentioned workflow is
described in the "Your Undivided Attention" podcast, episode 10, "Rock
the Voter" in an interview with a former Cambridge Analyticer insider.
Related: https://github.com/gorhill/uBlock
Related: cab6a5076c/README.md (policiesjson-45)
Related: https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
Apply a similar hack to the "all tabs" menu, as the appMenu has, so it
gets a proper height and doesn't jump above or below the "all tabs"
button, depending on the keyboard being displayed or not. With this
hack, it stays consistently above the button.
Adjust the menu for Firefox 94, and for having the tab bar and search
bar at the bottom.
Getting the appMenu to look decent took me forever to figure out, here's
a notable alternative version that always uses the full screen height:
#appMenu-popup {
margin-top: calc(-1 * 100vh) !important;
height: calc(100vh - 100px) !important;
max-height: calc(100vh - 100px) !important;
}
However with this alternative version, there's a bug when having the
keyboard open, then opening the menu (-> it will get spawned with about
half the screen size), and then closing the keyboard and opening the
menu again. The menu is cached (as one can see in the element inspector)
and still has the wrong height. The content inside the menu is
flickering between the full height and the half height.
By having a fixed size that looks good with both the keyboard open and
closed, we can work around this problem. The height of the keyboard was
adjusted for the PinePhone. If it doesn't look good on your device, add
a media query to make it have a different height based on the overall
height of the window (and possibly also width).
Based on MR 17 by plata-gl, thank you very much, and thanks to everybody
who answered the survey linked in that MR whether to make this default
or not.
I've left out padding-top since the additional 1px bar towards the top
looks like a bug, I've compared with Fennec on Android and it doesn't
have such a line. Also I've left out the inFullscreen lines from the MR,
not sure what they are for - we can still add them in a follow-up patch
if desired.
