Open Bug 1208222 Opened 9 years ago Updated 1 month ago

"Options" button open about:preferences in the end of tab list, so current tab may get lost

Categories

(Firefox :: Settings UI, defect)

defect

Tracking

()

People

(Reporter: arni2033, Unassigned)

References

Details

Attachments

(1 obsolete file)

All STRs in this bug are based on a model:
   open many tabs
-> open important tab (e.g. conversation) in the middle of the tab list
-> click Options button
-> open a new page OR click a link on about:preferences OR switch to other tab with Ctrl+(Shift)+Tab
=> [result]   there's no obvious way to return to the important tab

  [EXAMPLE. There's no need to perform these steps]
1. Open 100 tabs in new tab
2. Switch to the 50th tab, load https://github.com/ URL in that tab
3. Click menu (≡)->Options   [about:preferences will open in a new tab in the end of the list]
4. Click "Privacy" category, click "learn more" link   [a new tab with exciting info will open]
5. Press Ctrl+W to close that tab

Result:       Now any relatively quick action won't take you to Github tab
              (unless you remember its URL or title. "In the field" that's nearly impossible)
Expectations: options tab should be close in the tab list to previous active tab

Note:         This is actually a *regression* from firefox ~37 and shouldn't be marked as enhancement
Component: General → Preferences
Flags: needinfo?(jaws)
This is interesting. I don't know of any browser-related pages that we open up next to the active tab. If the preferences are opened at the end of the tab strip and then closed, the previously active tab should be switched to.

So I think this is an issue for two reasons:
1) If the user wants to refer to something on the previously active tab while in the preferences, this is made harder when the preferences are placed at the end of the tab strip.
2) If the user wants to keep the preferences open but return to the previously active tab, then the user will have to find the previously active tab in their tabstrip. This may take long and be error-prone when there are many tabs open.

On the other hand, I'm not sure what this change could mean for other in-content pages such as Customization and Add-ons that open their pages at the end of the tabstrip.

Philipp, what do you think?
Flags: needinfo?(jaws) → needinfo?(philipp)
It may be useful to make "Options" button middle-clickable (Ctrl+Clickable etc) to let user choose where he opens about:preferences page. But that is somehow inconsistent with "Home" button's middleclick behavior. (Also, see bug 1208208 for another interesting scenario)
I'm hesitant to change the default behavior since that could lead to all kinds of weird inconsistencies.

Using ctrl-click sounds enticing, but also like something that very, very few people would ever find or use. If we do it, the behavior should be the same for all tabs that get opened from the browser chrome (add-ons, options, etc.).
Flags: needinfo?(philipp)
Has STR: --- → yes
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> This is interesting. I don't know of any browser-related pages that we open
> up next to the active tab.

The view source tab?
(In reply to arni2033 from comment #0)
> All STRs in this bug are based on a model:
>    open many tabs
> -> open important tab (e.g. conversation) in the middle of the tab list
> -> click Options button
> -> open a new page OR click a link on about:preferences OR switch to other
> tab with Ctrl+(Shift)+Tab
> => [result]   there's no obvious way to return to the important tab

Closing the Preferences tab will return to the previously selected tab. Though that may not be obvious.

(In reply to jbrown from comment #5)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> > This is interesting. I don't know of any browser-related pages that we open
> > up next to the active tab.
> 
> The view source tab?

Thanks, also making a selection, context menu > Search SEARCH_ENGINE for "selection"...

That being said, both the view-source and context-menu search are tightly related to the selected tab. Preferences generally aren't tightly related to the selected tab.

The one exception is when people want to quickly get to the password manager to look up a saved password. We should make that process easier. Switching to in-content prefs made this worse, especially given bug 1012368.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6)
> Closing the Preferences tab will return to the previously selected tab.
It WON'T. And it won't do that in bug 1208208.
If you will close tab opened in Step 4 (i.e. if you add Step 6: "press Ctrl+W"), then Preferences tab will close, but it won't select the tab where I was when clicked Options button (tab from Step 2)
If it's still unclear, I will send a screencast.

Now I think that the best option is to simply open new window with single Preferences tab and let user do whatever he wants with that tab/window. (to be clear, I don't like "in-content" stuff)
Summary: "Options" button should open about:preferences page next to current page, not in the end of tab list → "Options" button open about:preferences in the end of tab list, so current tab may get lost
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6)
> (In reply to jbrown from comment #5)
> > (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> > > This is interesting. I don't know of any browser-related pages that we open
> > > up next to the active tab.
> > 
> > The view source tab?
> 
> That being said, both the view-source and context-menu search are tightly
> related to the selected tab. Preferences generally aren't tightly related to
> the selected tab.

They are if I want to add a cookie exception for the site (not working without them) I'm currently viewing.
Cookie exceptions would be better suited in the Control Center panel, which can be found when clicking on the (i) in the location bar. That area is currently being used to manage site-specific permissions, and cookie exceptions don't seem far off from it.
Originally I had (still have) similar issues with all in-content pages: mostly this bug & bug 1208208.
Now after some bugs became duplicate of this, I can't logically expand it to cover all in-content
pages like about:addons (?). If you think this bug should stay specific to about:preferences,
I'll have to file a new one, which I don't want. The same question for bug 1208208.

Probably I've already mentioned this, but I think it makes no sense discussing about:preferences w/o about:addons and Customize, because it's general problem. And also it's too easy to use this wrong argument here: "what requested in this bug was never the case for any in-content page". Expanding the bug from about:preferences to all in-content pages will resolve this.
Flags: needinfo?(jaws)
See Also: → 1327610
See Also: → 1327666
Yeah, I think if we change all of these pages (about:addons, about:preferneces, about:customizing) to act the same then I'm OK with the change.
Flags: needinfo?(jaws)
See Also: → 1378590
Severity: normal → S3
Attachment #9382901 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: