Arch Linux User Repository

gpg --keyserver keys.gnupg.net --recv-keys 85F86E317555BECC1C2184BF2C45BA09ABC5D7DA

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 http://demo.nimius.net/video_test/

https://archlinux.org/packages/extra/x86_64/firefox/

Dependencies (39)

[dbus-glib](https://archlinux.org/packages/extra/x86_64/dbus-glib/)
[ffmpeg4.4](https://archlinux.org/packages/extra/x86_64/ffmpeg4.4/)

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.

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).

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.

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

needs to be updated to latest firefox.

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

gpg --recv-keys --keyserver keyserver.ubuntu.com 2C45BA09ABC5D7DA
gpg: key 2C45BA09ABC5D7DA: public key "nikatar <nikatar@disroot.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

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

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

Minimize/Maximize/Close decorations disappear when title bar is turned off on the customize screen. https://gitlab.com/Thaodan/firefox-kde-opensuse/-/issues/8

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.

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

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: https://bugzilla.mozilla.org/show_bug.cgi?id=1672139

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

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.

@Louis

When using the Firefox package from the official repository, the window controls do appear, however, the appmenu patches are not applied: https://img.theaus.xyz/jIWYGHtU.png

@the-aus

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?

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

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: https://img.theaus.xyz/F6lBBOOK.png

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

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.

@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.

https://www.reddit.com/r/i3wm/comments/88k0yt/right_mouse_btn_instantly_clicks_first_option_in/

https://elementaryos.stackexchange.com/questions/17101/mouse-right-click-double-clicks

https://elementaryos.stackexchange.com/questions/16475/firefox-right-click-issue

@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 https://streamable.com/wrs3dj

@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

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

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

https://aur.archlinux.org/packages/hud/

@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

Can this package drop all the makedeps?

@nikatar

Thanks. That worked.

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

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.

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 macgeneral@macgeneral.de, 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 nikatar@disroot.org

# Contributor: Jan Alexander Steffens (heftig) jan.steffens@gmail.com # Contributor: Ionut Biru ibiru@archlinux.org # Contributor: Jakub Schmidtke sjakub@gmail.com # Compiled by: Arne Fahrenwalde macgeneral@macgeneral.de

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.

################# ORIGINAL HYPER-BABBLE NONSENSE

@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!

https://www.mozilla.org/en-US/MPL/2.0/

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)

SOOO YEAH!

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 developer.mozilla.org, hg.mozilla, and mozilla.org/firefox, 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 README.md 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/README.md ## 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.

gpg --keyserver keys.gnupg.net --recv-keys 85F86E317555BECC1C2184BF2C45BA09ABC5D7DA

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

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