Package Details: firefox-appmenu-bin 100.0.2-1

Git Clone URL: (read-only, click to copy)
Package Base: firefox-appmenu-bin
Description: Firefox-appmenu, binary version
Upstream URL:
Licenses: GPL, MPL, LGPL
Conflicts: firefox
Provides: firefox
Submitter: nikatar
Maintainer: nikatar
Last Packager: nikatar
Votes: 20
Popularity: 0.41
First Submitted: 2019-10-01 14:52 (UTC)
Last Updated: 2022-05-25 13:16 (UTC)

Dependencies (15)

Required by (136)

Sources (2)

Pinned Comments

nikatar commented on 2019-11-12 18:40 (UTC)

gpg --keyserver --recv-keys 85F86E317555BECC1C2184BF2C45BA09ABC5D7DA

Latest Comments

g3nsvrv commented on 2022-03-04 02:31 (UTC)

Please fix/add a missing dependency, the official firefox package requires ffmpeg4.4 in order to reproduce H264 videos, without it you have codec missing on these.

I tested on

Dependencies (39)


michaldybczak commented on 2022-02-09 19:33 (UTC) (edited on 2022-02-09 20:15 (UTC) by michaldybczak)

After installing Plasma 5.24 appmenu stopped showing up on Firefox. The same for thunderbird-appmenu-bin. EDIT: After a while, menus did show up. This is confusing and there seems to be some issues with appmenu applets.

FPSUsername commented on 2021-12-24 19:35 (UTC)

I noticed that when doing a reverse image search on Yandex, the uploaded image is corrupted and often shows as one color and sometimes with "scanline" artifacts. It only happens on Yandex and only on Firefox using Arch (no issues on Firefox Windows or Chromium (based) browsers on Linux).

prettyvanilla commented on 2021-12-18 04:55 (UTC)

Since this is only repackaging a prebuilt package from your GitHub-Repo please align the depends- and optdepends-array with the base package (remove mozilla-common & startup-notification, add xdg-desktop portal to optdeps). I noticed since chaotic-aur chooses to take this package for their repos and mozilla-common has long since been removed from the main repos.

nopeinomicon commented on 2021-12-08 00:24 (UTC)

The appmenu function is broken when using under Wayland on KDE Plasma 5.23.4. Only broken when Wayland is enabled, XWayland works fine.

KazuhiroShigeru commented on 2021-11-08 04:59 (UTC)

needs to be updated to latest firefox.

sandalswallow commented on 2021-06-27 12:14 (UTC)

try code below guys if you got gpg: keyserver receive failed: No name

gpg --recv-keys --keyserver 2C45BA09ABC5D7DA
gpg: key 2C45BA09ABC5D7DA: public key "nikatar <>" imported
gpg: Total number processed: 1
gpg:               imported: 1

nikatar commented on 2021-06-04 18:51 (UTC)

89.0-1 + fix_csd_window_buttons.patch + libdbusmenu-gtk3 in depends

bwbuhse commented on 2021-04-16 22:47 (UTC)

mozilla-common is no longer available. Is there going to be a fix for this?

ZorinArch commented on 2021-02-08 09:46 (UTC)

Minimize/Maximize/Close decorations disappear when title bar is turned off on the customize screen.

erayerdin commented on 2021-01-01 19:24 (UTC) (edited on 2021-01-01 19:26 (UTC) by erayerdin)

You can add GTK_USE_PORTAL=1 to desktop file to have it also support KDE dialogs.

For Maintainer

To test, go to a webpage and do CTRL+S. It will open up KDE file chooser after you use GTK_USE_PORTAL=1.

For Quick Workaround for End Users

Open up firefox.desktop.

kate /usr/share/applications/firefox.desktop

Find the first Exec key, which looks like below:

Exec=env UBUNTU_MENUPROXY=0 /usr/lib/firefox/firefox %u

Change it as:

Exec=env GTK_USE_PORTAL=1 UBUNTU_MENUPROXY=0 /usr/lib/firefox/firefox %u

Save, enter your password and done.

radleydark commented on 2020-12-17 09:33 (UTC)

After installing the package in firefox with titlebar turned off, the minimize / maximize / close buttons disappear

michaldybczak commented on 2020-12-04 19:05 (UTC) (edited on 2020-12-04 19:08 (UTC) by michaldybczak)

I'm starting to suspect that the issue lies somewhere with config gfx.webrender. For me gfx.webrender.all is disabled, but when I enable it and restart FF, it shows the buttons for a split of second then the buttons disappear. There is some bug with gfx.webrender:

lockeanarchist commented on 2020-12-04 03:03 (UTC)

I'm having the same problem with the window control buttons in CSD mode.

michaldybczak commented on 2020-11-19 16:28 (UTC)

I can confirm, that when titlebar is off, window control buttons doesn't appear, also on Plasma. There is just empty space. I thought that they may be invisible but no, it looks like there is no functional space in this area. I checked on various GTK themes but the result is the same. For me this isn't a big problem, because I prefer to use titlebar anyway.

the-aus commented on 2020-09-19 18:48 (UTC)


When using the Firefox package from the official repository, the window controls do appear, however, the appmenu patches are not applied:

Louis commented on 2020-09-19 16:10 (UTC)


It looks like there's reserved space for the window bottons at the left side in the first screenshot.

Have you tried installing the regular firefox-package with titlebars deactivated to see if the issue persists?

the-aus commented on 2020-09-19 01:58 (UTC) (edited on 2020-09-19 02:22 (UTC) by the-aus)

When installing this package, my window controls for Firefox disappear. Here's a screenshot compared to gnome-terminal (see top left):

The desktop environment that I'm using is Budgie, WM is mutter. (more info is in the neofetch in the screenshot if needed)

edit: When I enable the title bar setting within Firefox customization, the window controls reappear, but when taking away the title bar, they disappear again:

nikatar commented on 2020-07-12 15:02 (UTC) (edited on 2020-07-12 15:02 (UTC) by nikatar)

@xieve, oh lol, I wrote conflict instead conflicts in PKGBUILD. Fixed it

xieve commented on 2020-06-21 18:30 (UTC)

This isn't marked as conflicting/replacing Firefox, which means that pacman throws file exists in filesystem (owned by firefox) and aborts the installation when the original Firefox package is installed instead of asking whether one intends to replace it.

nikatar commented on 2020-05-16 23:50 (UTC) (edited on 2020-05-17 10:21 (UTC) by nikatar)

@LazyGeniusMan, I don't have this bug on my system. Maybe someone else will confirm.

As far as I heard, such problems may arise due to WM or compositor. Check out these discussions. I hope it helps you.

LazyGeniusMan commented on 2020-05-16 13:59 (UTC)

@nikatar, Hi, I have a weird bug. When Firefox is using my mic everytime I press right click the right click menu will duplicate. I did full uninstall (delete ~/.mozilla/firefox, /usr/lib/firefox* too) and reinstall but the problem still persist, even on safe mode.

Now I'm on firefox from official repo and it's not having this issue. Could you look into it ?

Video of this bug

nikatar commented on 2020-05-04 20:10 (UTC)

@AliTajelsir, yes, it's possible. But I think, that those who install this package know it. And they already have libdbusmenu-gtk3 installed, and they just want to get normal functionality for firefox with their appmenu-panel

alitajelsir commented on 2020-05-04 14:39 (UTC)

@nikatar, I think libdbusmenu-gtk3 should be included in the dependency list.

nikatar commented on 2020-04-21 14:48 (UTC)

For everyone who uses firefox-appmenu and/or thunderbird-appmenu(or their binary versions), my new package may be interesting:

nikatar commented on 2020-04-17 18:49 (UTC)

@andykluger,I just copied makedeps from original PKGBUILD for firefox-appmenu. As I understand it, this is not necessary. In the next release I will pay attention to this point

andykluger commented on 2020-04-16 19:45 (UTC)

Can this package drop all the makedeps?

Louis commented on 2020-01-14 21:05 (UTC)


Thanks. That worked.

nikatar commented on 2020-01-14 21:00 (UTC)

@Louis, it's strange. Try looking in preferences of Firefox.

Louis commented on 2020-01-14 20:44 (UTC)

I have my system language set to Danish in my Plasma desktop and firefox-appmenu-bin and firefox-i18n-da installed, but Firefox is still in English. No problems with thunderbird-appmenu-bin and thunderbird-i18n-da.

jmodo commented on 2019-11-13 03:28 (UTC)

CAUGHT MY MISUNDERSTANDING BEFORE SUBMISSION: I totally goofed. I had no idea you maintained the source based package as well, that makes way more sense. It may be noted somewhere, but until I searched for it with 'yay -s firefox-appmenu' to check that it installs well enough, I would have never known otherwise. But I am a blind bat...

So not to have wrote all this for absolutely nothing, and since you already maintain the source package, I'll change my scope to teeny suggestions for improving both.

The fact that I couldn't tell where the code used to build this was, goes to show that this package still falls just short of proper COMPLIANCY! Hehehe.

Ignore all my nonsense below, I'm going to leave it since it's not utterly worthless info, and maybe one day it helps someone somehow, heh. TBH, I thought you had patched in support yourself, (I don't use, and don't really know anything about, appmenu), but clearly if I was to read the header comments, there were patches of varying source, I would recommend clearing things up in two ways.

I: Update firefox-appmenu-bin's PKGBUILD to clearly reflect origin of this binary, so it was compiled by Arne Fahrenwalde, FANTASTIC!!! Where's his source then?! :P OH Jan Steffens maintains this? Hmm, I can't tell him anything regarding licensing! Things are messy.

In the AUR, we're free to be verbose with comments, so I abuse that, I'd header the PKGBUILD as so,

Maintainer: Nikita Tarasov

# Contributor: Jan Alexander Steffens (heftig) # Contributor: Ionut Biru # Contributor: Jakub Schmidtke # Compiled by: Arne Fahrenwalde

It's super-duper misleading to leave the maintainer listing Jan Steffens, it gives it undue "clout", and I don't think they'd appreciate it, even if your intention is to show that the majority of the PKGBUILD is their work, do that with comments. like.....

## Built from sources provided by AUR/firefox-appmenu, also maintained by $USER # this build script is adapted from extra/firefox PKGBUILD, with few changes aside from inclusion of appmenu patches # so a big thanks to arch-repo packaging god, Jan Steffens, for maintaining the PKGBUILD I've unforgivingly molested, # whith patches from #source, #source and #source

And aside from comments, definitely add to the package description to make clear to all, up front, that this binary package is built from sources at AUR/firefox-appimage, I often only read up on packages in the terminal, so I would have had to make assumptions, and would have just passed up on this package as is.


@nikatar it seems you missed the point of @American_Jesus's comment... The problem isn't the fact it's hosted on your personal github/gitlab/etc repo, but that you are distributing binary packages with seemingly no availability of your source code.

Since you've essentially created your own Firefox build, differing from upstream, you have to comply with the Mozilla Public License (MPL2.0), and you are not in compliance here.

Read the agreement you're required to adhere to, now that you've distributed your own modified binary release, you can't just host a binary without providing us the freedom to inspect all source code involved, particularly any changes, modifications, patches, etc, so we can study it, modify it, share it, fork it, f%3k it, whatever!!!! But by only delivering a binary release, you are infringing on our rights! Hindering our freedom!! Heh, but seriously, you are not in compliance, see the link, and except I've copied here, as well as my suggestions for bringing this PKGBUILD into compliance after that.

The offending secion is 3.2, and potentially 3.3 (the pairing of firefox with appmenu may be considered a larger work, I don't know that appmenu is, or entails). Since you do not comply with 3.2/B, the rights granted to you to distribute by section 2.1 are not currently valid, as you've not met all conditions detailed in 2.7, so your license to distribute is thereby not valid, and you're essentially infringing on the rights of all prior contributors until compliance is reached. I'm copying the essential issues, but you should read it all, considering it's your license now, too!

2.1. Grants

Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license:

A) under intellectual property rights (other than patent or trademark) Licensable by such Contributor to use, reproduce, make available, modify, display, perform, distribute, and otherwise exploit its Contributions, either on an unmodified basis, with Modifications, or as part of a Larger Work; and

B) under Patent Claims of such Contributor to make, use, sell, offer for sale, have made, import, and otherwise transfer either its Contributions or its Contributor Version.

2.7. Conditions

Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted in Section 2.1.

3.2. Distribution of Executable Form

If You distribute Covered Software in Executable Form then:

B) such Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient;

3.3. Distribution of a Larger Work

You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s)


In a nutshell you gotta reach this...

your.code.appmenu.code.license.files.PATCH + firefoxUpsteamCode = the source code you used to produce these binary releases, and BAM! you'll have an MPL/2.0 license compliant distribution (granted appmenu's license is wholly compatible, I still haven't googled it)

So my suggested roadmap to compliance!

Create a new git repo "firefox-appmenu-bin" you are wholly compliant once all code needed to build the same binary is freely accessible, and LICENSE(S) are shared and compatible.

I'd suggest not pulling in all of upstream, just give credit to mozilla and link to, hg.mozilla, and, and maybe the current tarball in new readme, mention MPL/2.0 license(s), you don't need to provide upstream code itself, since they do it already, and better than we ever could. (but if you absolutely need to (you don't), you can pull the trunk in as asub:module from hg, over to git using hg-git, or use the mozilla/gecko-dev mirror to do the same, but that's extra messiness with no readily apparent benefits imo)

Compile your additions to source into a patch, share upstream urls, have LICENSE(s), and a detailing a way to go from what you're providing,to a binary release, the exact same code should be shared and used to build by you, and anything withheld would make it a different release, requiring a different source code to be shared... so no funny biznizz. Oh, share the same build instruction in the readme that you have used to make your release binary, as well. You can include alternative build instructions as well.

So to break it down to the bits and bytes, inodez and wide loads...

At a minimum, your repo should be looking like this....

/firefox-appmenu-bin/ /firefox-appmenu-bin/LICENSE ## (MPL/2.0+any necessary for appmenu code) /firefox-appmenu-bin/ ## See my ramblings about that below /firefox-appmenu-bin/add-appmenu-compatibility.patch

whether you provide an amended PKGBUILD there is your call, but might as well move it, for simplification.

You should definitely switch to this repo to host release binaries, as well. Then it's obvious that source and binary are available for all, from the end-user, casual meth-abusers, holier than thou free software losers (just pokin' the beehive, with corny wack rhymez pulled from my behind, I'm one of 'em), and their lawyers who will take you on over a packaging issue... they are the literal worst. So yeah! Read licensing agreements! And learn the proper way to adhere to licensing criteria when distributing from now on, so I don't have to get my hands so dirty!

All I need to feel freer, and therefore might even consider installing this package, is a simple readme linking upstream, a diff patch of your changes to upstream, license, that's pretty much it! I know this feels ridiculous, why the need for a binary release, but rules are rules!

Should be a simple thing to accomplish, since you already have your source. Run a diff on it vs upstream, and pipe into a patch file! Them licensing compliance will be yours! Or don't and keep denying me freedom, get your package flagged, piss off Richard Stallman's team of suits, end up homeless & ~/homeless, all because you didn't share the sauce.

nikatar commented on 2019-11-12 18:40 (UTC)

gpg --keyserver --recv-keys 85F86E317555BECC1C2184BF2C45BA09ABC5D7DA

nikatar commented on 2019-10-01 21:05 (UTC)

What do you have in mind? The binary stored on my GitLab repo, because it is not possible on AUR. Also the binary is signed with my pgp-key for security reasons.Thus, even if my GitLab and AUR accounts are hacked, you can always make sure whether I am the author of this package

American_Jesus commented on 2019-10-01 16:37 (UTC)

Why is this a binary stored on a random site and no link pointing to source?