We decided after we added Flashblock that Web Features needed to be redone for 1.6. Bryan has the Flashblock whitelist all ready to go, but we need to free up some space for that button first. I had suggested before that we remove the tab-focus prefs, which will help a bit (anyone who really cares about setting those is someone who can handle setting hidden prefs...).

"Play animated images only once" might be one that we could consider removing the UI for as well, as this isn't something people tend to change very often (or at all, now that our ad-blocker hides most of the annoying ones).

Another approach is the split the window in half, with Annoyance blocking on one side, and Content Control on the other. I'll attach a screen capture. But I think we should avoid what Firefox does in its Advanced tab where there is another set of tabs. Too much clicking to find new features. I also agree that the 'tab selects' section don't really fit there, but I couldn't see a better place for it.

Thanks for mocking that up, Bryan. It looks really busy (and cramped) to me :( It also is completely out of sync with the design of the rest of the prefPanes ;) so it's probably not the way to go. We don't want to do tabs, that's for sure (we want to bust up Appearance if we can ever figure out a good way to do so).

(In reply to comment #1) > "Play animated images only once" might be one that we could consider removing We exposed "animated images" to help with perf, because they suck at perf. Maybe we could set the pref to once in all-camino and remove the UI, and anyone who really likes constant looping can re-enable it via the hidden pref. Except that "breaks" the ability to toggle on and off for that one image someone's "got to see animated" (without visiting about:config, which we like to avoid having people use)...hmm.

(In reply to comment #4) > It looks really busy (and cramped) to me :( It also is completely out of sync > with the design of the rest of the prefPanes ;) so it's probably not the way to > go. Well, it was worth a shot :) But I completely agree. Unfortunately, I like all the prefs so wanted to come up with a way that we could save them. (Save the Prefs!) But on the topic of culling, we could also remove the "Scale images to fit" pref and just default to one or the other (Firefox vs. Safari), with the option to configure in about:config. If we decide to remove any, I'd like to see them added to the Hidden Pref documentation: http://www.caminobrowser.org/documentation/hiddenprefs/ When I first started using Camino, that page was really helpful (and user friendly).

Culling "Scale images to fit" sounds good; I think Firefox removed that recently, too. I think I'd default to scaling enabled, fwiw. And, yes, I fully intend to document whatever prefs we remove here on /hiddenprefs/ :)

(In reply to comment #7) > Culling "Scale images to fit" sounds good; I think Firefox removed that > recently, too. I think I'd default to scaling enabled, fwiw. It is removed from the Fx 2.0.0.4 prefpanes, and scaling is enabled by default. There was some weak protest about it in the forums. (In reply to comment #5) Defaulting to play once for animated gifs will break a number of sites that use this to show slide-show kind of things.

I fully support axing image scaling. More than that, I'd put Java and Plug-ins on the chopping block for consideration as well. Do we think a significant number of people really turn off plugins? (I know Simon and Pink do, but they aren't typical users.) I think there's a reason Flash, Java, and F4M account for so many incoming bugs.

Image scaling split into 401964, since it seems non-controversial.

If we leave the tab selection, one thing that would reduce the "My god, it's full of checkboxes" effect would be to convert the checkboxes for that pref to a single popup list: Tab selects: Text fields All form controls All form controls and links I find it very unlikely that enabling links without also enabling form controls is at all common.

As the person who initially implemented that, yeah, I agree. Anybody who really cares can about:config it.

I don't necessarily disagree with the premise of comment 11, but the actual results mean we're *adding* another option (negating any space benefit from bug 401964). I'd much rather axe the whole block than do comment 11. Swapping that (adding links) is really a power-user feature.

(In reply to comment #13) > I don't necessarily disagree with the premise of comment 11, but the actual > results mean we're *adding* another option (negating any space benefit from bug > 401964). Huh? Turning two check boxes into a popup with three options removes a state and takes less space. > I'd much rather axe the whole block than do comment 11. Swapping that (adding > links) is really a power-user feature. Links perhaps, but adding form controls is not. We had enough backlash when we previously switched to following the OS setting that we added the prefs.

(In reply to comment #14) > Huh? Turning two check boxes into a popup with three options removes a state > and takes less space. Sorry, I saw "list" and missed "popup", and ended up at "list of radio buttons". > > I'd much rather axe the whole block than do comment 11. Swapping that (adding > > links) is really a power-user feature. > > Links perhaps, but adding form controls is not. We had enough backlash when we > previously switched to following the OS setting that we added the prefs. Which is why our default setting is "text fields and form controls"; no one ever has to add form controls. The only thing they have to add is links, which is a power-user feature. I still favor axing that block, but I'm no longer opposed to comment 11 now that I can read :P if I can't convince the axe to fall ;)

(In reply to comment #15) > The only thing they have to add is links, which > is a power-user feature. I would object to treating that as a 'power-user feature'. People with all kind of disabilities find that useful. Ever broke bones in your (right) hand, to the point that it is more than painful to use a mouse ?

FWIW, I turn off Java, but not plugins.

Here's another radical idea: remove "Block pop-up windows" (which is on by default) and leave (somehow) just the Exceptions List.

So the history of enabled plugins is that we took it out before 0.9 because it was broken, then added in back in for 1.5 because we could (bug 331293). Unfortunately I don't see any discussion of whether we *should* have put it back though. Was there some demand for it during the 1.0 timeframe when it was missing that's not reflected in bugzilla? Does anyone have a compelling reason not to remove the UI for it?

Here's one possibility. Changes, for reference: - Removed Plug-in toggle - Converted tab selection to a popup - Put Flash block up in the annoyances section, where it really seems to fit better - Reordered annoyance blocking section. I'm not that happy about having the longest item first, but I tried a bunch of different orders, and having the big button at the end instead of in the middle really helps reduce the cluttered look. Comments welcome.

I'm going to assume that since no-one has objected to comment 20, that means everyone loves it ;) This implements that new arrangement, leaving camino.enable_plugins as a hidden pref that will take effect on new window once it's changed. This patches fixes bug 368937 to the extent that it would still be valid.

Oops, same thing bug fixing bug 356204 for this pane as well.

corresponding nib

Comment on attachment 297999 [details] [diff] [review] v2 >+const int kFocusTextFields = 1; > const int kFocusForms = (1 << 1); >+const int kFocusLinks = (1 << 2); The first one should be (1 << 0) to match its neighbors. These should be static, and so should the kAnnoyancePref* constants that follow. >+ tabFocusValue |= kFocusTextFields; What is this |= business? tabFocusValue started out at 0, you can do a straight assignment without needing to OR anything in.

(In reply to comment #24) > What is this |= business? I originally had a reverse-order non-breaking switch statement that stacked them, then remembered that this isn't Perl and readability counts ;) I just forgot to change the |= when I rearranged it.

Comment on attachment 298000 [details] nib This looks OK, except the button should be indented (and was in your screenshot). r=ardissone with that fixed. One day I'd like the optical-illusion mess that is the Whitelist sheet fixed, but that day is not today.

(In reply to comment #26) > This looks OK, except the button should be indented (and was in your > screenshot). I meant to comment about that... why should it be? We don't indent buttons anywhere else in the prefs.

It's subordinate to that particular pref (as the enabling/disabling shows); none of the other buttons in prefs are subordinate to any particular pref, and most of the other buttons are actually separate "pref groups"/"sections" (i.e., 17px) from other semi-related prefs.

Landed on trunk and MOZILLA_1_8_BRANCH with comments 24 and 26 addressed.