The old preferences window used to open the category where you left off. For example if you were in "privacy" it would open the window directly in "privacy". The same behavior should be applied to in-content preferences (the add-ons manager already does that).

I don't see for what history.state is good for and I don't see it remembering anything (what I think it should do). So I exchanged it with a check for a pref (browser.preferencesInContent.lastSelected). The dialog prefs are using the localstore.rdf to remember the last open pane. If you want to use this for the inContent prefs then someone other should take this bug as I'm not experienced enough for this.

Fang, I don't think we should continue to support this behavior. Switching back to the previously viewed pane doesn't make much sense if more than a couple days have passed since viewing the preferences. Are you OK with wontfix'ing this bug and keeping the current behavior? (as well, removing this behavior from the add-ons manager?)

Yeah I agree in Preferences this feature doesn't add much value, I think we can just wonfix this and open the "General" panel by default. I'm not so sure about Add-ons though, it's true that the previous category might not be relevant anymore. But open the "Get Add-ons page" by default doesn't seem right either since it's designed towards first-time add-ons users. Maybe we should leave the Add-ons page as it is till we have a better designed "Get Add-ons Page".

Ok, thanks for the feedback Zhenshuo and also the patch Richard, even though we'll close this bug out without it.

But should be something done with: if (history.length > 1 && history.state) { selectCategory(history.state); ...?

I understand the rationale behind wontfixing here, but just note that the advanced category always remember where it was left off.

(In reply to Richard Marti (:Paenglab) from comment #5) > But should be something done with: > if (history.length > 1 && history.state) { > selectCategory(history.state); > ...? Yeah, we should still clean this up. Can you file a separate bug? (sorry for the run-around)

(In reply to Guillaume C. [:ge3k0s] from comment #6) > I understand the rationale behind wontfixing here, but just note that the > advanced category always remember where it was left off. We should break apart the advanced preferences so that we don't have the separate panes within it. Doing so would remove this quirk.

(In reply to Richard Marti (:Paenglab) from comment #5) > But should be something done with: > if (history.length > 1 && history.state) { > selectCategory(history.state); > ...? This is handled in bug 1013523 now.

Bugger - WONTFIX kinda sucks here IMO. I agree it "doesn't add much value", but it adds *some* value. Given there is a patch, no apparent argument that it actually hurts anyone, and even a work-around on file for it, I think we should reconsider.

Imo, it would also have some cons, making the behavior non-predictable for most users. Advanced users may find value here, but I suspect others (that is the majority of our users) would be confused by always ending in a different pane. Most apps on Windows open preferences on the first pane regardless from where you left the previous time.

(In reply to Marco Bonardo [:mak] from comment #12) > Imo, it would also have some cons, making the behavior non-predictable for > most users. Advanced users may find value here, but I suspect others (that > is the majority of our users) would be confused by always ending in a > different pane. Most apps on Windows open preferences on the first pane > regardless from where you left the previous time. IMHO this is only kind of valid if you define user = new user; maybe there are users of the already existing userbase of xxx millions relying on/got used to the old behavior and it should be engineered against that userbase - as should (have to) be done for a lot of more recent changes. Btw, this looks like a policy issue and not an engineering issue -> i.e. firefox-dev?

(In reply to XtC4UaLL [:xtc4uall] from comment #13) > IMHO this is only kind of valid if you define user = new user; maybe there > are users of the already existing userbase of xxx millions relying on/got > used to the old behavior I don't think you can't bring any fact related to the old dialogs behavior to a totally different ui, we have broken the behavior enough here that it's hard to define existing userbase expectations. They expect a preferences dialog, we are giving totally different ui, at that point any user is "new" since they don't know what to expect from the new ui. I should add the also the old behavior was confusing and complicating support (I did some remote support sessions with parents/friends and being able to tell where they were after opening prefs always complicated things). Moreover as I pointed out, is not even common in the OS that covers vast majority of our users. If we want to change the behavior this is the only valid time, when completely replacing the ui. Btw, sure, firefox-dev may be the right choice.

I see 2 somewhat distinct issues here: * Session Restore should be considered independently. On session restore, we go to great lengths to restore the exact state of every tab - the scroll position, the form data, etc. IMO, restoring the session should, as far as possible, restore Fx back to exactly how it was left. If I tweaked a preference then restarted for the preference to take effect (or even if an update installed itself *while* I was in the prefs tab), I'd expect to find the prefs tab opened to the same place I left it. Fang, what's your position on this? * Re the more general question of restoring the state: Fang, is it your position that "it's OK to WONTFIX this" or "it's *best* to WONTFIX this"? I'm happy to defer to UX if it is the latter, but IMO it was an obvious bug that annoyed me enough to file a duplicate, so I'd hate to see this WONTFIX'd by default. Fang, if you'd prefer to take this to a wider audience (or would like me to), then I'm happy with that - but also happy to defer to you if you think that's unnecessary.

(In reply to Mark Hammond [:markh] from comment #15) > I see 2 somewhat distinct issues here: > > * Session Restore should be considered independently. On session restore, > we go to great lengths to restore the exact state of every tab - the scroll > position, the form data, etc. IMO, restoring the session should, as far as > possible, restore Fx back to exactly how it was left. If I tweaked a > preference then restarted for the preference to take effect (or even if an > update installed itself *while* I was in the prefs tab), I'd expect to find > the prefs tab opened to the same place I left it. Fang, what's your > position on this? I agree with your point here on general session restore, if I'm in Preferences while Firefox crashed and I restored my last session, then ideally we should restore all tabs to exactly how they were left, including the preferences tab. But this is an edge case. In general, most users don't change the same preferences again and again. If they closed the Preferences page, the next time they open it, most people probably want to change a different preference instead of the same one. That's why I don't see a point of openning the same preferences category. > * Re the more general question of restoring the state: Fang, is it your > position that "it's OK to WONTFIX this" or "it's *best* to WONTFIX this"? > I'm happy to defer to UX if it is the latter, but IMO it was an obvious bug > that annoyed me enough to file a duplicate, so I'd hate to see this > WONTFIX'd by default. > > Fang, if you'd prefer to take this to a wider audience (or would like me > to), then I'm happy with that - but also happy to defer to you if you think > that's unnecessary. I think we should wonfix this bug and open General by default when users open Preferences page, because this behavior is expected and cause less confusion. I'm happy to discuss this with the rest of the UX team in the next design critique and update the feedback here.

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #16) > In general, most users don't > change the same preferences again and again. If they closed the Preferences > page, the next time they open it, most people probably want to change a > different preference instead of the same one. Do you have statistics for this? (I'm requisting info from Mark, because Fang's account seems to be disabled.) Sebastian

(In reply to Sebastian Zartner from comment #19) > Do you have statistics for this? (I'm requisting info from Mark, because > Fang's account seems to be disabled.) I'm not aware of any.

Then you should probably add some telemetry to measure whether Fang was right with her assumption. Should I create a new report for that? Sebastian

(In reply to Sebastian Zartner from comment #21) > Then you should probably add some telemetry to measure whether Fang was > right with her assumption. That's a difficult thing to measure. In comment 2, jaws talks about "if more than a couple days have passed" - in which case I agree the resolution of "don't remember" is correct. OTOH, when I re-open preferences in some shorter period, I *do* want it to remember - I'm probably toggling/editing the same thing I was before. But basing it on the time period is complex, potentially confusing and simply not worth the effort. So if we have to choose between potentially confusing vs a minor convenience, I agree convenience must lose. YMMV. Personally I'd prefer it remembered, but concede the counter-point. > Should I create a new report for that? It's not clear what you want to measure - but even if it was, I'd be surprised if it was judged worth the effort.

Does the attached patch work, or was there something more to add? Maybe it could be spun into a simple extension...

It worked for me, but I don't know if it still would work.

(In reply to Mark Hammond [:markh] from comment #22) > (In reply to Sebastian Zartner from comment #21) > > Then you should probably add some telemetry to measure whether Fang was > > right with her assumption. > > That's a difficult thing to measure. In comment 2, jaws talks about "if more > than a couple days have passed" - in which case I agree the resolution of > "don't remember" is correct. OTOH, when I re-open preferences in some > shorter period, I *do* want it to remember - I'm probably toggling/editing > the same thing I was before. > > But basing it on the time period is complex, potentially confusing and > simply not worth the effort. So if we have to choose between potentially Basing it on the time period is surely not a good way to go. The only sane options are keeping it as it is or change it to always switch to the last selected category. > > Should I create a new report for that? > > It's not clear what you want to measure The basic point is to find out how often people toggle the same preference in the options in relation to how often they change other options. Though this would surely need to be defined more precisely. > but even if it was, I'd be surprised if it was judged worth the effort. I tend to agree. It might be too much effort for this small convenience. OTOH it affects a huge amount of people and the collected info might also be used to improve other parts of the UX (e.g. by collection info on which options are changed most). Sebastian

For what it's worth, the act of tweaking a preference, trying it out, and re-tweaking is made a lot simpler with in-content preferences. In this scenario, the user can keep the preferences tab open while using the rest of the browser, and the selected pane won't change. With the windowed preferences on Windows, this interaction behavior was not an obvious capability to most users since it is not common for a modal-looking dialog to allow to be backgrounded. On OSX the sheet couldn't be foregrounded while the preferences were open, so this wasn't even a possibility there.

why this annoying issue wnat not be resolved? why the tab is not stored as until ff37?

I never use General, I always use Privacy. So why I have to find the tab Privacy and I have to select it every day? I dont agree.

As Yorgos says--for some of us, at least, that's the place we go to 99.99% of the time when we go to Preferences. A separate keyboard shortcut to go directly to that pane would solve this, actually (along with fixing the other keyboard shortcut issues). The real thing is, this isn't a "preference": it's where we go to get information we need that's stored in the browser. Not seriously suggesting moving it elsewhere, just that if we had a time machine, it might should have been put elsewhere originally. Some background: like most people, we have dozens or hundreds of logins at various sites. We don't use a password manager (yeah, that would solve this another way, but). We do store passwords in Firefox, also password-protected. So when we go to JoesHamsterShack.com for the first time in a year, if Firefox fills in the password for me, great; but when my wife yells from upstairs, "What's the password for JoesHamsterShack?", I need to go look it up. This happens *A LOT*. I had it down to muscle memory: <alt>T,O,<alt>P, enter password, type Joesham -- ah, there it is, <alt>P again, type password, yell back to her. Now it takes 10x as long (not exaggerating). Yes, I'm a keyboard guy. Not the only one.

Just as a note from User-Advocacy, this is the number one complaint from users about the new in-content prefs. As we will be removing the old style in Firefox 41, re-implementing this would bring significant happiness to power-users who used this in previous versions. It doesn't seem to have any negative effects on other users either.

Sorry a question. What means wontfix? developers dont want to fix it or it will be fixed in ff41?

(In reply to Tyler Downer [:Tyler] from comment #34) > Just as a note from User-Advocacy, this is the number one complaint from > users about the new in-content prefs. As we will be removing the old style > in Firefox 41, re-implementing this would bring significant happiness to > power-users who used this in previous versions. It doesn't seem to have any > negative effects on other users either. We evaluated this and decided not to support it in the in-content preferences. It may match expected behavior when compared to previous versions of Firefox, but it is not expected behavior for Settings/Preference windows elsewhere in operating systems or web browser software. For example, opening Settings on Windows 10 brings the user to the default Settings view. Same goes for Internet Explorer, Chrome, etc. However, with the new in-content preferences, users can make a bookmark that points to about:preferences#privacy and clicking on that bookmark will always take them to the Privacy pane of preferences. This should be a sufficient workaround.

(In reply to Yorgos from comment #37) > browser.preferences.inContent = false (thanks God). This preference is going away very soon. Please use the bookmark method as described in the previous comment.

Remembering previous pane makes sense even if a month has passed. why? I used to switch between font sizes like this when there was a separate preferences panel: To change minimum font size to 24 first time: Alt+E N RtArrow RtArrow RtArrow Alt+A Alt+O 24 Enter Next time to change minimum font size to 12 (even after a month): Alt+E N Alt+A Alt+O 12 Enter With in-content preferences I have to do this all the time: (to change minimum font size to 12) Alt+E N Tab DnArrow DnArrow Alt+Shift+A Alt+Shift+O 12 Enter (to change minimum font size to 24) Alt+E N Tab DnArrow DnArrow Alt+Shift+A Alt+Shift+O 24 Enter What's the point of calling this keyboard "shortcut" when it is no longer better than working with a mouse! Conclusion: In-content preferences are of no worth because they make keyboard-shortcut operations worthless. In-content preferences totally strip the power users of all their power. Hence an option to disable such obstructive feature should always be available (like browser.preferences.inContent) which allows powers users to retain their power.

With separate preferences panel one could reach the minimum font size option with 4 keystrokes. With current in-content preferences, on needs seven key strokes including two triple strokes to arrive at the same settings. Bookmarking the preferences#contents page reduces that effort to 5 key strokes that still contain 2 triple key strokes which is somewhat a relief than default in-content preferences page. Here's the recipe assuming bookmark C points to about:preferences#content page. Alt+D C Enter Alt+Shift+A Alt+Shift+O 12 Enter

Ajay, but I never use shortcut! for me its very very important the old behaviour (destroyed by Mozilla). It requires more clicks to go the same effects.

I already explained my point of view and my disappointing with this forced choice Incontent that open itself always onthe first tab (General), even if I use only Privacy tab.