From ArchWiki

Multimedia playback

possible to note (somewhere around Open-with extension) that video playback can be handled via a window manager key binding or shortcut like bindsym $mod+m exec mpv -- $(sselp) for i3wm or similar Ubone (talk) 05:11, 20 June 2018 (UTC)Reply[reply]

Dictionaries for spell checking

I'm using Firefox stable version (61.0-1) and it no longer creates symbolic links to the system dictionaries.

Now it uses this about:config key: "spellchecker.dictionary_path"

—This unsigned comment is by J1simon (talk) 14:27, 27 June 2018 (UTC). Please sign your posts with ~~~~!Reply[reply]

Screenshot of webpage


no need to list every possible way

Why not? They're not the same, moz://a might remove the new one, it may not work for someone, etc. ― Ubone (talk) 10:04, 27 July 2018 (UTC)Reply[reply]

Mozilla won't remove the main way, there is no reason it shouldn't work, the developer toolbar will be removed in Firefox 62.[1] --Larivact (talk) 11:58, 27 July 2018 (UTC)Reply[reply]
ok that explains the removal but was there really a need for the rewrite? ― Ubone (talk) 13:04, 27 July 2018 (UTC)Reply[reply]
The previous version was alright, I just made some slight improvements, like dropping irrelevant info ("Firefox 57", "Page actions") and elaborating why the Save button is misleading. --Larivact (talk) 13:51, 27 July 2018 (UTC)Reply[reply]
I can't call it an improvement when the reading entropy has increased. ― Ubone (talk) 14:52, 27 July 2018 (UTC)Reply[reply]
How so? --Larivact (talk) 15:21, 27 July 2018 (UTC)Reply[reply]
It's repetitive and unclear. ― Ubone (talk) 15:56, 27 July 2018 (UTC)Reply[reply]
Fixed it. --Larivact (talk) 16:33, 27 July 2018 (UTC)Reply[reply]
Please do not silently revert my edits without stating a reason. I thought I addressed your concern. --Larivact (talk) 10:46, 28 July 2018 (UTC)Reply[reply]
no not really, but respected your addition and it is there ― Ubone (talk) 11:00, 28 July 2018 (UTC)Reply[reply]


The last sentence wrongly implies that the above method doesn't work when you block HTML canvas.

about:config?filter=privacy.resistFingerprintingUbone (talk) 06:44, 21 August 2018 (UTC)Reply[reply]

You're right that does break it, contrary to #1412961 being marked as fixed. --Larivact (talk) 06:54, 21 August 2018 (UTC)Reply[reply]
please abstain from rewording ― Ubone (talk) 06:59, 21 August 2018 (UTC)Reply[reply]
Sorry, I just did. --Larivact (talk) 07:06, 21 August 2018 (UTC)Reply[reply]
special:diff/536510 Enabling privacy.resistFingerprinting does not break screen shooting but it does require per site confirmation, you might want to think more ― Ubone (talk) 07:18, 21 August 2018 (UTC)Reply[reply]
On my system it breaks; please be a bit more respectful. --Larivact (talk) 07:23, 21 August 2018 (UTC)Reply[reply]
as i already wrote, it breaks on all systems and is unbroken on per site basis, also please don't accuse me of being not respectful in the same thread you gave me a middle finger just 17 minutes prior ― Ubone (talk) 07:30, 21 August 2018 (UTC)Reply[reply]
and to be clear this wasn't an offence but an observation ― Ubone (talk) 07:38, 21 August 2018 (UTC)Reply[reply]
I deselected Always remember my decision in the prompt which breaks screen shooting. I didn't intentionally neglect you, I just missed your message. --Larivact (talk) 08:20, 21 August 2018 (UTC)Reply[reply]

Dark themes

RE: Special:Diff/552276. How exactly is copying and editing a .desktop file less complex than simply adding a setting to about:config ? And what's so unreliable about changing the content process's theme? -- nl6720 (talk) 07:02, 1 November 2018 (UTC)Reply[reply]

The .desktop file is optional, it's just a simple variable. I've used css before and found it did not work well sometimes. They are really two different solutions that give similar results but are not the same. We could have both. The css is rightfully in the tweaks page as it may even give more flexibility for those who choose to have it. The main page only hints a standard option. --Ubone (talk) 07:21, 1 November 2018 (UTC)Reply[reply]
I don't understand how a .desktop file is optional. Where else can you set GTK_THEME so that it applies only to a specific application and not globally? My proposed solution wasn't to use the mostly non-working CSS workaround from Firefox/Tweaks#Unreadable input fields with dark GTK+ themes, but to set the content process's theme with widget.content.gtk-theme-override. -- nl6720 (talk) 07:37, 1 November 2018 (UTC)Reply[reply]
You can do GTK_THEME=Adwaita firefox in your terminal emulator or bind GTK_THEME=Adwaita firefox to a key in your window manager, for example. The .desktop file is one of the options a user has. widget.content.gtk-theme-override is already in the tweaks page and that's ok. --Ubone (talk) 07:51, 1 November 2018 (UTC)Reply[reply]
Not everyone uses window managers. Anyway, I still think that Firefox#Dark themes should link to Firefox/Tweaks#Unreadable input fields with dark GTK+ themes, otherwise readers might never think of looking there. -- nl6720 (talk) 08:04, 1 November 2018 (UTC)Reply[reply]
See what happens when there's no link from Firefox#Dark themes to Firefox/Tweaks#Unreadable input fields with dark GTK+ themes. -- nl6720 (talk) 14:03, 16 December 2018 (UTC)Reply[reply]
I wonder if the links should be in reverse order. I understand you put the link there because it's a firefox page but my reasoning for this is 1/ the tweaks page has a lot more information so the gtk link could be quicker to give what some may want; and 2/ the link is quite long and kinda makes the sentence lose balance; or it maybe should be removed because it's already in the tweaks page --Ubone (talk) 16:06, 22 December 2018 (UTC)Reply[reply]
I think the link is needed, since most people would not think to look at Firefox/Tweaks. -- nl6720 (talk) 08:48, 23 December 2018 (UTC)Reply[reply]
no the other one --Ubone (talk) 13:00, 23 December 2018 (UTC)Reply[reply]
You mean "GTK#Themes"? I didn't remove it because I thought that you want to keep that link there. I have no objections to removing it. -- nl6720 (talk) 16:23, 23 December 2018 (UTC)Reply[reply]

Smooth scrolling

Is this really relevant for recent releases of Firefox? I tried the tweaks and it actually made things worse.

Shelter (talk) 09:46, 10 May 2020 (UTC)Reply[reply]

GNOME keyring integration

There is a broken package link in Firefox#KDE/GNOME integration. I researched a bit and I found out that the AUR package has been deleted because it is not compatible with a current Firefox/Thunderbird version. It is also not even available via anymore. If the addon has been abandoned I would be in favor of removing this from the list.

NetSysFire (talk) 00:41, 31 January 2021 (UTC)Reply[reply]

Removed that bit and renamed that section to just "KDE integration". -- Svito (talk) 04:54, 31 January 2021 (UTC)Reply[reply]

Hardware video acceleration

The page states "Nvidia's proprietary driver does not support VA-API and DMA-BUF so this feature will not work on that driver," however Hardware video acceleration#Installation mentions libva-vdpau-driver providing a VDPAU backend for VA-API, so with nvidia supporting VDPAU surely this combination provides video acceleration in Firefox? Mbromilow (talk) 02:46, 18 May 2021 (UTC)Reply[reply]

The problem is DMA-BUF, not VA-API. Rumors say NVIDIA driver 470 will have DMA-BUF and Wayland support so let's wait until then to add this back to wiki N0k0m3 (talk) 16:21, 22 May 2021 (UTC)Reply[reply]
I agree with N0k0m3. NVIDIA has confirmed they are working on DMA-BUF support, for now we should wait. I will edit the page to clarify DMA-BUF support is the blocking issue. For now should we remove the "The factual accuracy of this article or section is disputed" banner? Vchernin (talk) 06:51, 1 June 2021 (UTC)Reply[reply]
I added all currently known nvidia dma-buf information to the tips area of that section. I removed the warning as all information that might be useful is contained, if there's anything else that should be mentioned for nvidia users feel free to add it. Vchernin (talk) 06:13, 2 July 2021 (UTC)Reply[reply]

Under environment variables it states "MOZ_DISABLE_RDD_SANDBOX=1 to disable RDD sandbox, see [9]." However this can be achieved by setting media.rdd-vpx.enabled to false. Furthermore, the given link does not actually mention the MOZ_DISABLE_RDD_SANDBOX=1 variable. I don't see a need for this bullet point in it's current form. Vchernin (talk) 06:52, 2 July 2021 (UTC)Reply[reply]

In the Tips section it is mentioned that the h264ify extensions can be used to disable some codecs. I think it's simpler to use about:config. For example I set media.av1.enabled to false. ENV25 (talk) 06:17, 4 April 2022 (UTC)Reply[reply]

This is a great tip, thanks for sharing! I used this to get consistent video encoding on YouTube on my Intel Ivybridge system. I set media.av1.enabled to false as you did, since it's not supported by libva-intel-driver, and I also set media.mediasource.vp9.enabled to false, since Ivybridge does not support VP9 decoding, as indicated by Hardware video acceleration#VA-API drivers. This was enough to deter YouTube from using the av01.0.05M.08 and vp09. video codecs, but seemingly without breaking playback of videos that are encoded in with them without any alternatives. I (unscientifically) tested this and this AV1 video, as well as this VP9 video, and they all play with my configuration (with Firefox politely not using hardware acceleration for the format). From my understanding, these settings use to totally enable/disable support for the codec, but this doesn't look to be the case anymore. Perhaps they are now mere suggestions, to allow sites like YouTube to provide alternatives?
As I can see no downside to having these settings set when warranted by the hardware, I do think we can recommend this instead of the extensions. There's some more work involved, as the user has to determine which workarounds they need before they go disabling settings, but I still like it more than the extension. In addition to referencing the support table, it would good to get a list of the codecs that YouTube can throw at users, if there are more than AV1, VP9, and H.264/AVC. Thanks, CodingKoopa (talk) 04:57, 7 April 2022 (UTC)Reply[reply]
I stand corrected. After looking at the source code, it looks like this preference does control whether AV1 will be decoded at all. I was finally able to tease out this behavior using this sample. I can conclude that using these settings may unexpectedly break videos outside of YouTube, so we can't really recommend it (at least, not without noting this caveat). Thanks, CodingKoopa (talk) 03:02, 8 April 2022 (UTC)Reply[reply]

Scrollbar is not hidden/disabled when YouTube is fullscreen

I've found that you can disable overlay-scrollbars in about:config to solve the problem with YouTube and other pages. To do that I set widget.gtk.overlay-scrollbars.enabled to false.

Vitoyucepi (talk) 04:33, 18 March 2024 (UTC)Reply[reply]

You don't even need to go to about:config. Enabling Settings -> General -> Browsing -> Always show scrollbars works the same way.
Vitoyucepi (talk) 11:14, 19 March 2024 (UTC)Reply[reply]