Talk:Firefox
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)
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 ~~~~!
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)
- 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)
- 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)
- The last sentence wrongly implies that the above method doesn't work when you block HTML canvas.
about:config?filter=privacy.resistFingerprinting
― Ubone (talk) 06:44, 21 August 2018 (UTC)
- You're right that does break it, contrary to #1412961 being marked as fixed. --Larivact (talk) 06:54, 21 August 2018 (UTC)
- 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)
- special:diff/536510 Enabling
- On my system it breaks; please be a bit more respectful. --Larivact (talk) 07:23, 21 August 2018 (UTC)
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)
- 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)
- 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 withwidget.content.gtk-theme-override
. -- nl6720 (talk) 07:37, 1 November 2018 (UTC)
- I don't understand how a .desktop file is optional. Where else can you set
- You can do
GTK_THEME=Adwaita firefox
in your terminal emulator or bindGTK_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)
- You can do
- 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)
- 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)
- 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)
- 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)
- 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)
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)
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 addons.mozilla.org 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)
- Removed that bit and renamed that section to just "KDE integration". -- Svito (talk) 04:54, 31 January 2021 (UTC)
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)
- 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)
- 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)
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)
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)
- 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
tofalse
as you did, since it's not supported by libva-intel-driver, and I also setmedia.mediasource.vp9.enabled
tofalse
, since Ivybridge does not support VP9 decoding, as indicated by Hardware video acceleration#VA-API drivers. This was enough to deter YouTube from using theav01.0.05M.08
andvp09.00.51.08.01.01.01.01.00
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)
- 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)