I see no preview for files stored in a ntfs partition mounted on boot on neon unstable.
The same files have preview when stored in my Home formatted with EXT4 file system.

I have connected another drive with ext4 fs and i can see previews on it, so I guess its a NTFS problem?

Could be related to recent change
https://invent.kde.org/frameworks/kio/-/merge_requests/702
https://invent.kde.org/system/dolphin/-/merge_requests/323

À priori, it should not have any effect on ntfs mount.

Could your ntfs mount be done through fuse ?
Could you share the result of `mount` command.

Changing status

My ntfs partition is /dev/sda3.

$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=3965768k,nr_inodes=991442,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=804344k,mode=755,inode64)
/dev/sda2 on / type ext4 (rw,noatime,discard)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755,inode64)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=20921)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/var/lib/snapd/snaps/chromium-ffmpeg_24.snap on /snap/chromium-ffmpeg/24 type squashfs (ro,nodev,relatime,x-gdu.hide)
tmpfs on /tmp type tmpfs (rw,noatime,inode64)
/var/lib/snapd/snaps/bare_5.snap on /snap/bare/5 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core18_2344.snap on /snap/core18/2344 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gifex_3.snap on /snap/gifex/3 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_12725.snap on /snap/core/12725 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/deadbeef-vs_6.snap on /snap/deadbeef-vs/6 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core18_2284.snap on /snap/core18/2284 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-26-1604_104.snap on /snap/gnome-3-26-1604/104 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-28-1804_145.snap on /snap/gnome-3-28-1804/145 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/qt551_37.snap on /snap/qt551/37 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1515.snap on /snap/gtk-common-themes/1515 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gtk2-common-themes_13.snap on /snap/gtk2-common-themes/13 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/snapd_14978.snap on /snap/snapd/14978 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1519.snap on /snap/gtk-common-themes/1519 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/qt513_23.snap on /snap/qt513/23 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_12821.snap on /snap/core/12821 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/qt513_24.snap on /snap/qt513/24 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/opera_167.snap on /snap/opera/167 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/spacepurge_1.snap on /snap/spacepurge/1 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-34-1804_72.snap on /snap/gnome-3-34-1804/72 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/peek_711.snap on /snap/peek/711 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/opera_166.snap on /snap/opera/166 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-28-1804_161.snap on /snap/gnome-3-28-1804/161 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/snapd_15177.snap on /snap/snapd/15177 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-34-1804_77.snap on /snap/gnome-3-34-1804/77 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/qt551_39.snap on /snap/qt551/39 type squashfs (ro,nodev,relatime,x-gdu.hide)
/dev/sda3 on /mnt/DADOS type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
/etc/auto.2TB on /CIFS1 type autofs (rw,relatime,fd=6,pgrp=1321,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=44231)
/etc/auto.WD on /CIFS2 type autofs (rw,relatime,fd=12,pgrp=1321,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=43261)
/etc/auto.SEAGATE on /CIFS3 type autofs (rw,relatime,fd=18,pgrp=1321,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=43263)
/etc/auto.WIN7 on /CIFS4 type autofs (rw,relatime,fd=24,pgrp=1321,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=42530)
/var/lib/snapd/snaps/chromium-ffmpeg_26.snap on /snap/chromium-ffmpeg/26 type squashfs (ro,nodev,relatime,x-gdu.hide)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=804340k,mode=700,uid=1000,gid=1000,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

My mounted NTFS is on sdc1 and sdb1

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=8150480k,nr_inodes=2037620,mode=755,inode64)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p6 on / type ext4 (rw,noatime)
[...]
/dev/sdc1 on /commonDisks/F type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/sdb1 on /commonDisks/G type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
[...]

*** Bug 451441 has been marked as a duplicate of this bug. ***

*** Bug 452109 has been marked as a duplicate of this bug. ***

*** Bug 452097 has been marked as a duplicate of this bug. ***

> /dev/sda3 on /mnt/DADOS type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

> /dev/sdc1 on /commonDisks/F type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
> /dev/sdb1 on /commonDisks/G type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

Indeed that's because your mounts are actually using fuseblk.

The bug is due to fact fuse mounts are assimilated to nfs filesystem, here wrongfully in kcoreaddons:
https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kfilesystemtype.cpp#L129

The way to fix it, is not clear to me, we need to determine "real" filesystem for the fuse block but I don't know exactly how to do it.
Probably using fuse API statfs, http://libfuse.github.io/doxygen/structfuse__operations.html#a4e765e29122e7b6b533dc99849a52655

workaround: mount ntfs file systems with ntfs3 driver available since kernel 5.15 instead of ntfs-3g.

https://wiki.archlinux.org/title/NTFS

(In reply to Patrick Silva from comment #11)
> workaround: mount ntfs file systems with ntfs3 driver available since kernel
> 5.15 instead of ntfs-3g.
> 
> https://wiki.archlinux.org/title/NTFS

Yeah, nice idea, but this doesn't work for other FUSE filesystems like exFAT, gzipfs, mergerfs or sshfs.

This happened to me too, after a full upgrade 2 hours ago.

My NTFS partition is really local, on the same drive as OS/user (btrfs) partition.
But needs rising "remote" limit (in Dolphin) to get previewing in NTFS to work.

I'm wondering if it could just grep `mount` output and see what's the mount point?
Something like `/dev/sda2` or `/dev/nvme0n1p2` is enough to assume it's local.
(maybe not really enough. but of course fallback methods could be used)

BTW my current system state, useful for tracing:

Operating System: Artix Linux x86_64
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Kernel Version: 5.17.4-artix1-1 (64-bit)

And, Dolphin 22.04.0

(In reply to NaitLee from comment #13)
> This happened to me too, after a full upgrade 2 hours ago.
> 
> My NTFS partition is really local, on the same drive as OS/user (btrfs)
> partition.
> But needs rising "remote" limit (in Dolphin) to get previewing in NTFS to
> work.
> 
> I'm wondering if it could just grep `mount` output and see what's the mount
> point?
> Something like `/dev/sda2` or `/dev/nvme0n1p2` is enough to assume it's
> local.
> (maybe not really enough. but of course fallback methods could be used)
> 

if your system has a mount like:
/dev/sda2 on /mnt/my-ntfs-mount type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

That's expected, that's the bug, the workaround is to use ntfs-3g mount method instead of fuse which is probably the default one on your system.

Technical details in https://bugs.kde.org/show_bug.cgi?id=451408#c10

I can also confirm this happening on my kubuntu system. I thought it was a Dolphin issue so I downgraded Dolphin and related software kio-extras, kdegraphics-thumbnailers, dolphin-plugins, libdolphinvcs5 to version 21.12.3 and it worked properly again. I however how to upgrade the system again to version 22.04.0,

Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Kernel Version: 5.15.0-25-generic (64-bit)
Graphics Platform: X11
Processors: 12 × Intel® Core™ i5-10400 CPU @ 2.90GHz
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 660 Ti/PCIe/SSE2

As mentioned before, this is not happening on the OS drive, only other drives. I think version in the bug report should be changed to 22.04

*** Bug 452919 has been marked as a duplicate of this bug. ***

(In reply to chrisgualo from comment #16)
> *** Bug 452919 has been marked as a duplicate of this bug. ***

Yes, I can confirm the same is happening on my system also. Setting the remote files preview to a very high limit (10GB) solves it for me. Now all the previews on my locally mounted (NTFS) drive show up.

System details:
Operating System: Manjaro Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Kernel Version: 5.15.30-xanmod1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2080/PCIe/SSE2

*** Bug 453186 has been marked as a duplicate of this bug. ***

*** Bug 453251 has been marked as a duplicate of this bug. ***

To those concerned, this change was intentional.

NFS, SMB, SSHFS are not local file-systems, as such previewing files on those can be slow, network-intensive and lowers the overall performance when browsing such filesystem.
We have been plagued by bugs about those network filesystems and their limitations especially when mounted using mount/fstab. This makes it harder to categorize as remote which they are. We recently made some progress on that front, and that's the cause of this behavior change and the bug in the NTFS/fuse case.

Unfortunately, this impacted NTFS fuse-mounted fs. We wrongfully categorize them as remote FS (because historically fuse usecases were remote filesystems). We can improve upon this situation but this is not very clear how yet.
Details in comment https://bugs.kde.org/show_bug.cgi?id=451408#c10
I have made a lot more researches and the situation is that our libraries come short to help.
I have opened a bug upstream that if fixed would help solve the NTFS issue https://github.com/tuxera/ntfs-3g/issues/36

There is a very simple workaround to all of those issues in Dolphin > General > Preview, crank up the file limit size for which to compute previews for remote files, as much as you feel is needed.

Still folders preview won't be affected as they require a lot more work to obtain a preview, they are currently disabled for remote filesystems. That might be something we can improve upon, offering an option for instance.

We might revert the change to please users, but I'd rather fix the issues, now that they are exposed.

(In reply to Méven Car from comment #20)
> Unfortunately, this impacted NTFS fuse-mounted fs. We wrongfully categorize
> them as remote FS (because historically fuse usecases were remote
> filesystems). We can improve upon this situation but this is not very clear
> how yet.
> Details in comment https://bugs.kde.org/show_bug.cgi?id=451408#c10
> I have made a lot more researches and the situation is that our libraries
> come short to help.
> I have opened a bug upstream that if fixed would help solve the NTFS issue
> https://github.com/tuxera/ntfs-3g/issues/36

I left a comment on that, maybe it helps.

As a workaround, it might be possible to query udisks (resp. solid) for the
filesystem type in the case of fuseblk. Those mounts require access to the
block device and thus were very likely mounted through udisks, which knows
the type of the filesystem.

(In reply to Méven Car from comment #20)
> Still folders preview won't be affected as they require a lot more work to
> obtain a preview, they are currently disabled for remote filesystems. That
> might be something we can improve upon, offering an option for instance.

I'm a big fan of that idea. Just give an option to enable folder previews for remote filesystems.
A simple checkbox, nothing fancy. May of cause be disabled by default.
It's quite frustrating that I don't have folder previews anymore for months now.
And it would be nice if I would have the option to enable them on remote filesystems as well.
My internet is quite fast, so this shouldn't be a problem (at least for me).

*** Bug 453287 has been marked as a duplicate of this bug. ***

Please make an option for folder previews. I'm ok with rising the limit but lack of option for folder previews is not a good thing.

*** Bug 453435 has been marked as a duplicate of this bug. ***

We have reverted the incriminating commit.
https://invent.kde.org/frameworks/kio/-/commit/be7d351a8ac4cccc5e66b1d278326e6f26ead1c0

We will revisit this, once we have improved our ntfs/fuse detection.

*** Bug 453549 has been marked as a duplicate of this bug. ***

Made an account here just to comment on this issue.

I was quite surprised when directory previews would no longer show for my cifs network storage mount.

Disabling previews by default for this case is fine with me, as long as there is an option to ignore any limits. 

My network storage is connected with a 10 Gbit/s link and has plenty of I/O and CPU capacity, so I really want to make use of file previews on this “remote” file system in my local network.

Thanks for considering

*** Bug 453839 has been marked as a duplicate of this bug. ***

(In reply to Michael Stapelberg from comment #28)
> Made an account here just to comment on this issue.
> 
> I was quite surprised when directory previews would no longer show for my
> cifs network storage mount.
> 
> Disabling previews by default for this case is fine with me, as long as
> there is an option to ignore any limits. 
> 

There is one already, Dolphin > configure > Previews > Size limit for network files.
It defaults to no files, meaning regardless of a file size no preview will be generated.
It applies when you kio to access network mounts aka urls like smb:/ or nfs:/
And until we reverted the change that caused this bug also nfs or smb regular mounts.

> My network storage is connected with a 10 Gbit/s link and has plenty of I/O
> and CPU capacity, so I really want to make use of file previews on this
> “remote” file system in my local network.
> 
Not everyone has a 10Gbit/s link to their mounts, we have to tune things for small capacity.
As having things tailored for a lot a resources but not having them is far worse than the opposite.
But of course we want to provide the ability to tune things further than our cautious default.

(In reply to Méven Car from comment #30)
> (In reply to Michael Stapelberg from comment #28)
> > Made an account here just to comment on this issue.
> > 
> > I was quite surprised when directory previews would no longer show for my
> > cifs network storage mount.
> > 
> > Disabling previews by default for this case is fine with me, as long as
> > there is an option to ignore any limits. 
> > 
> 
> There is one already, Dolphin > configure > Previews > Size limit for
> network files.
> It defaults to no files, meaning regardless of a file size no preview will
> be generated.
> It applies when you kio to access network mounts aka urls like smb:/ or nfs:/
> And until we reverted the change that caused this bug also nfs or smb
> regular mounts.

I tried changing that, but it only seems to apply to individual file previews, not to directory previews.

No matter what I set as the limit, directory previews wouldn’t show up on my remote file system.

Only upgrading to kio 5.93.0, where the commit was reverted, helped.

*** Bug 453879 has been marked as a duplicate of this bug. ***

*** Bug 454174 has been marked as a duplicate of this bug. ***

I can confirm that this is working now with the latest update. Thanks to everyone involved!

Yes, Finally! I can see thumbnails of image/pictures on NTFS drives once again using krusader file manager

Does someone knows if this will fix the problem for folder preview on a system partition too or I have to file a new bug?

Oh, I just realized I'm with 5.94 and the bug is still here and I forgot I already filed a bug:
https://bugs.kde.org/show_bug.cgi?id=453497

That's a different issue from the one described here.

Yes I see that :)

Created attachment 150625 [details]
gbit networking is plenty fast for previews.

For those with fast networking, patch against kio-5.92 attached. It's not very clean; I just took a sledgehammer to this code.

The fraction of new issues I encounter with KDE that turn out to be deliberately introduced, is starting to worry me a bit. :)

(In reply to FeepingCreature from comment #40)
> Created attachment 150625 [details]
> gbit networking is plenty fast for previews.
> 
> For those with fast networking, patch against kio-5.92 attached. It's not
> very clean; I just took a sledgehammer to this code.

Care for some proper patch ?
> 
> The fraction of new issues I encounter with KDE that turn out to be
> deliberately introduced, is starting to worry me a bit. :)

You are welcome to contribute, as you do with your comment or more constructively with code review or code.

We try to be transparent about our decision process (https://bugs.kde.org/show_bug.cgi?id=451408#c30) and when we do make mistakes (here a wrong assumption than local drive are to be recognized as local drives), we make amend provided we get the feedback needed to realize the drawback of the changes.

Because most devs are benevolent, we can't reproduce all the configurations the users will use and test those, so we have a tendency to focus on standard issues in our testing (here no ntfs fuse mounts, few of us use nfs mounts or samba).

Plus all users don't have the same needs, i.e not all have high speed networks, SSD or high CPU count, we have to tailor things down to the light slimbooks of the world and where networking is slow and/or expensive while allowing to take advantage of more capable systems.

> You are welcome to contribute, as you do with your comment or more constructively with code review or code.

Let me explain why I don't care to contribute. Paradoxically, it's because KDE is too good.

Firefox was in a weird sort of usability maximum pre version 57. They were held back by their UI architecture from making improvements; XUL was perceived as a millstone holding Firefox tethered to an outdated and overflexible model, and anyway JS based addons should be enough for anyone. So they broke compatibility with TabMixPlus, and usability took a massive dive off a cliff for me and never recovered.

Does that mean they were wrong to break addon compatibility to try to compete with Chrome? Should Quantum be reverted? I don't think so, because ergonomic maxima are always subjective. I have a bunch of patches on my local system for KDE apps; for instance, I have Gwenview set up so that it automatically fullscreens images on fullscreen mode and switches back to folder view on un-fullscreen. This workflow represents a very specific sort of "desire path" in usability, but I have zero way of proving that it fulfills a general need. Analogously, "just show thumbnails for absolutely everything" is a patch that's hyperfocused on the fact that I store practically all my data on a local NAS, but this is not the "normal" way in which network drives are used. Or maybe it is! I don't know? Instead of a patch, should I make a usability study? Should I go study design theory and user psychology?

KDE is for me at a local maxima in usability, at least in part because the way it currently works represents a well-worn groove in my mind and workflow. Any change taken will move it from this maximum, and that may be the correct decision! As with the classic story about fighter plane seats, there is no such thing as an average user, and I realize that I'm further from average than most. As such, I don't care about getting this patch upstreamed, because I am not even convinced that you are wrong to have the settings in upstream the way they are; this is not a bug, it's a varying requirement. However, the beauty of opensource is that for software that is not as rapidly developed as Firefox, we can easily keep our local collections of patches going. Hence you should take my comment purely as grumbling - and merely an attempt to save a small bit of time for people who feel the same way. :)

*** Bug 459903 has been marked as a duplicate of this bug. ***