now that bug 41526 has landed, we need some way to disable this "feature" that I can't imagine normal humans ever using on a regular basis... Ok, so "set as wallpaper" is great and all, and it was one of the main complaints from CNet about NS6.1 and was 4xp... I have no problem with it existing, but we need some (documented) method to disable the feature. And here's why. 1. The current implementation doesn't really fulfill the spec optimally. See http://mozilla.org/projects/ui/menus/shortcut/ below Where's Set as Wallpaper? 2. The current location is just below "Save Image..." which makes it painfully easy to hit by accident. 3. There is no way to undo the operation without knowing what your wallpaper was beforehand and making the change in the control panel 4. Some campanies (mine included) do not want their employees changing settings or backgrounds etc. if NS is going to have a Client Customizations Kit, they will probably want to be able to turn this off. there are probably others, like "how often do you use it anyway?" but I think these are enough for now... optimally it would be nice to have a pref for this that would be set to on by default so that those of us who have accidentally changed our wallpaper caould turn it off so it wouldn't happen again.

While waiting for this bug to be fixed (chances are it won't be), in comm\content\communicator\contentAreaContextOverlay.xul you'll want to delete the following lines: <menuitem id="context-setWallpaper" label="&setWallpaperCmd.label;" accesskey="&setWallpaperCmd.accesskey;" oncommand="gContextMenu.setWallpaper();"/> in order to remove "Set As Wallpaper" from the context menu.

An easier fix, albeit a little less thorough, is to add the following lines to the file userchrome.css in the chrome subdirectory of your profile folder: #context-setWallpaper { display: none !important; }

WONTFIX based on nice userchrome.css workaround?

Reading comment 1: The actual bug (setting the wallpaper accidentally annoys me) is no longer exists since the 'set as wallpaper' context menu option now generates a confirmation dialog. suggest RESOLVE FIXED

Filter "spam" on "guifeatures-nobody-20080610".

Wow. thank goodness for bug spam to raise these things from the depths of bugzilla. Moving to fixed for the following reasons: 1) firefox doesn't have this option and we have all survived 2) there is a userchrome.css workaround for those using the suite 3) even for the suite, there is a confirmation box to prevent accidental triggering.

Mike Young: It is considered bad form to verify a bug you resolved. I am re-opening because of this. Also, it's in the product "Mozilla Application Suite", not "Firefox", so this is a SeaMonkey bug.

As mentioned in comment 6, the suite now has a confirmation dialog, so Mike is correct in that this bug isn't relevant any more. FIXED, however, is not the correct resolution; WONTFIX would probably be the best resolution here.

Mike, Thanks for filing this bug in the first place. Now, even if you don't care anymore, others (still) do. *** Workaround (works, but) is profile-based, and can't be discovered by "normal" users. I concur with a (hidden) preference and not showing this item by default. Neil, do you agree with that (plan) ?

(In reply to comment #0) > 4. Some campanies (mine included) do not want their employees changing settings > or backgrounds etc. If there's some documented code that will read the Windows Group Policy setting for backgrounds then perhaps we should use that.

(In reply to comment #7) Sorry about the bad form. I usually leave it for the reporter to verify, but the reporter was me and I worried it might go another 3 years without an update. I marked it "fixed" because the dialog resolves at least 1 of the concerns I raised originally. (In reply to comment #10) > If there's some documented code that will read the Windows Group Policy setting > for backgrounds then perhaps we should use that. The quirk here is that if the user has the Group Policy set, I am fairly certain it renders the "Set as Wallpaper" button useless anyway. (I'm not in front of a windows machine right now, but this was the route we took, and IIRC, the feature functions, but the background never changes.) So in response to the original 4 reasons: 1) No one uses that spec anyway - "invalid" 2) There's a confirmation box now - "fixed" 3) This is still true, but there's no way Mozilla should fix it... we're not a background chooser service - "wontfix" 4) Windows Policies (exist for all now-supported releases of windows but didn't originally) prevent this from occurring anyway, so the only change for mozilla would be a UI-tweak to lose the menu option. I'd guess that some users might want to turn this off without needing full-out Windows Policies, but I'm not in favor of the preferenc-ification of every option, and really windows policies is the place to lock down backgrounds anyway.

Based on Comment 11, this is a WONTFIX