1252102 - Offending pages about:preferences and Customizing inconsistently open on new tab page

Status: NEW

(Firefox :: General, defect)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160225030209
STR:
1. Launch new profile. Open new tab (Ctrl+T)
2.A) Open Menu bar (F10) -> Tools -> Options
2.B) Right-click Australis menu button (≡), click "Customize..."

AR:
 A) Preferences page opened instead of the tab I opened in Step 1
 B) Customizing page opened in a new tab, leaving my carefully opened tab untouched [OK]

ER:  Either X or Y
 X) In both scenarios (A and B) new page should open in a new tab
 Y) In both scenarios pages should follow the same behavior defined by developer,
    e.g. to open in a new window due to bug 1208208 and bug 1208222.

As you may see, I don't find (B) a mistake. I filed this bug as inconsistency among special pages

This is regression from bug 1014185. Regression range:
> https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=f9e4a56281d86c553b8cedd9cb86025813946ec0&tochange=c34fe673bb97d511920d2986cb84057f62e0c4a0

Comment 1

[Andrew Overholt [:overholt]]

ni(Dao) based on regression range.

Comment 2

[arni2033]

@ Dao:   (spam)
If it's possible, please do not hurry to fix this for ~2 days, because I'm going to file another bug which is supposed to question the whole "replace New Tab page" concept (similarly to my bug 1231025)
with listing all disadvantages. It's probably worth reading that bug before starting any work here.

Comment 3

[arni2033]

Bug 1276125 is the long-standing bug I was talking about in comment 2. That's it.

Comment 4

[Andrew Overholt [:overholt]]

For me, about:preferences only seems to open in the existing about:newtab if I have 2 about:newtabs open. I was going to change the summary to be "about:preferences opens in currently open tab when open tabs are all about:newtab" but is that inaccurate?

Comment 5

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

I tried to repro this on my win10 machine while doing triage with Andrew and we both were unable to repro with STR. Note: I was not using a clean profile.

In any case, if the about:preferences opens up in an existing tab it is definitely inconvenient but I think if the end-user would "go back one page" by clicking the back-arrow they would not lose their existing tab. While this is a valid bug, it is not release blocking and too late to fix in Fx47.

Comment 6

[arni2033]

 >>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160531030258
(In reply to Andrew Overholt [:overholt] from comment #4)
> I was going to change the summary to be "about:preferences opens in currently open tab
> when open tabs are all about:newtab" but is that inaccurate?
That would be inaccurate, because (1) I still reproduce comment 0 without extra steps (2) Options and Customize(before bug 1014185) pages opening in new tab without history is intentional, and people who implemented it (Jaws?) may want to preserve that behavior despite usability problems I reported.
More accurate summary would be "Customize page doesn't load in about:newtab"

(In reply to Ritu Kothari (:ritu) from comment #5)
> In any case, if the about:preferences opens up in an existing tab it is
> definitely inconvenient but I think if the end-user would "go back one page"
Huh, Alt+Left and "Back" button are unavailable in Options and Customize(before bug 1014185) pages opened in about:newtab without history.
I think it was intentional, so I filed bug 1276125 to list all issues I encountered with that behavior
Your suggestion (to keep about:newtab in tab history) would fix one of the cases in bug 1276125.

Comment 7

[Dão Gottwald [:dao]]

(In reply to arni2033 from comment #0)
> >>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160225030209
> STR:
> 1. Launch new profile. Open new tab (Ctrl+T)
> 2.A) Open Menu bar (F10) -> Tools -> Options
> 2.B) Right-click Australis menu button (≡), click "Customize..."
> 
> AR:
>  A) Preferences page opened instead of the tab I opened in Step 1
>  B) Customizing page opened in a new tab, leaving my carefully opened tab
> untouched [OK]
> 
> ER:  Either X or Y
>  X) In both scenarios (A and B) new page should open in a new tab
>  Y) In both scenarios pages should follow the same behavior defined by
> developer,
>     e.g. to open in a new window due to bug 1208208 and bug 1208222.
> 
> As you may see, I don't find (B) a mistake. I filed this bug as
> inconsistency among special pages
> 
> This is regression from bug 1014185. Regression range:
> > https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=f9e4a56281d86c553b8cedd9cb86025813946ec0&tochange=c34fe673bb97d511920d2986cb84057f62e0c4a0

(A) is longstanding behavior so that when people who open a new tab and then decide to go to preferences, the blank tab doesn't get left behind. I haven't seen many complaints about that behavior and I suspect we don't want to change it.

(B) is the "regression" because customize mode isn't even a page, it just uses a tab as a placeholder. It doesn't really feel like a page either, since you can't navigate in that tab. We could implement A's behavior for this but it's not going to be a priority.

Comment 8

[arni2033]

(In reply to Dão Gottwald [:dao] from comment #7)
> (A) is longstanding behavior so that when people who open a new tab and then
> decide to go to preferences, the blank tab doesn't get left behind.
Then why don't you check whether user visited new tab by pressing Ctrl+T? (the same mechanism that allows you to go back to "parent" tab when you open new tab from that tab using Ctrl+T)
It's a change in behavior that was present for decade - "don't touch tabs when user opens Options".
Also, it's not necessary to delete about:newtab from tab history for this, see comment 5 -> comment 6.
You're trying to guess what user wants - it always brings different problems to real-world users.
> I haven't seen many complaints about that behavior
bug 1188800 + bug 1197600 + bug 1276125

> We could implement A's behavior for this
I've never asked for this specifically... If current behavior (inconsistency among "special pages") is intentional, close this bug as wontfix and bug 1188800 as fixed. 
But why did you implemented (A) behavior initially then? This just seems like there's no plan at all.
Is is possible that the next day about:preferences will "break" to current Customize page state, and you'll be OK with it, because "it used to open in new window and doesn't feel like a normal page"?

> because customize mode isn't even a page, it just uses a tab as a placeholder.
> It doesn't really feel like a page either, since you can't navigate in that tab.
It's a page, as it's opened in a tab and placed directly in content area. XUL page, but still a page.
Also, I was able to navigate in that tab before bug 1014185. But now it's just causing another bug

Comment 9

[Dão Gottwald [:dao]]

(In reply to arni2033 from comment #8)
> (In reply to Dão Gottwald [:dao] from comment #7)
> > (A) is longstanding behavior so that when people who open a new tab and then
> > decide to go to preferences, the blank tab doesn't get left behind.
> Then why don't you check whether user visited new tab by pressing Ctrl+T?

I don't understand the question. Whether the new tab was opened using Ctrl+T or some other method is irrelevant to what I wrote.

> (the same mechanism that allows you to go back to "parent" tab when you open
> new tab from that tab using Ctrl+T)
> It's a change in behavior that was present for decade - "don't touch tabs
> when user opens Options".

Options used to be a dialog, so logically there was no way how it could replace a new tab. It's a page now so things are different.

> Also, it's not necessary to delete about:newtab from tab history for this,
> see comment 5 -> comment 6.

It's actually necessary for technical reasons if I remember correctly, but we're getting off-topic. There's a bug on file for this somewhere.

> You're trying to guess what user wants - it always brings different problems
> to real-world users.
> > I haven't seen many complaints about that behavior
> bug 1188800 + bug 1197600 + bug 1276125

Even if we ignore that two of those three bugs were also filed by you and the other one is obsolete, that's still not many complaints.

> > We could implement A's behavior for this
> I've never asked for this specifically... If current behavior (inconsistency
> among "special pages") is intentional, close this bug as wontfix and bug
> 1188800 as fixed. 
> But why did you implemented (A) behavior initially then? This just seems
> like there's no plan at all.

Because we felt like reusing the new tab will more often match the user's intention, and the loss of closing a new tab that the user did want to keep around isn't all that big.

> Is is possible that the next day about:preferences will "break" to current
> Customize page state, and you'll be OK with it, because "it used to open in
> new window and doesn't feel like a normal page"?

Sorry, I don't understand the question.

> > because customize mode isn't even a page, it just uses a tab as a placeholder.
> > It doesn't really feel like a page either, since you can't navigate in that tab.
> It's a page, as it's opened in a tab and placed directly in content area.
> XUL page, but still a page.

I don't want to fight over definitions. Feel free to call it a page, but the way we present it to the user is quite different from any other page.

Comment 10

[arni2033]

(In reply to Dão Gottwald [:dao] from comment #9)
> Whether the new tab was opened using Ctrl+T or some other method is irrelevant to what I wrote.
You wrote exactly "(A) is longstanding behavior so that when people who open a new tab and then decide to go to preferences, the blank tab doesn't get left behind." 
This is the case when new tab is opened via Ctrl+T (or button) specifically. So it doesn't mean that you need to break new tab in other cases to "fix" this particular case. In other words:
that case is not a reason to break other cases you haven't mentioned. I hope it explains my comment.

> Options used to be a dialog, so logically there was no way how it could replace a new tab.
> It's a page now so things are different.
Yeah, so the bug appeared. "Don't mess with user tabs" was behavior for ages, so users never expected that. I mentioned this to show that your point about user expecting new tab to be closed (and deleted from tab history) is not valid. Also, earlier you "felt like reusing the new tab will more often match
the user's intention", but now (apparently) you don't, as you removed that mechanism. It gives me hope

> we're getting off-topic. There's a bug on file for this somewhere.
It's part of bug 1276125; I don't know how to move discussion to that bug

Comment 11

[Dão Gottwald [:dao]]

(In reply to arni2033 from comment #10)
> (In reply to Dão Gottwald [:dao] from comment #9)
> > Whether the new tab was opened using Ctrl+T or some other method is irrelevant to what I wrote.
> You wrote exactly "(A) is longstanding behavior so that when people who open
> a new tab and then decide to go to preferences, the blank tab doesn't get
> left behind." 
> This is the case when new tab is opened via Ctrl+T (or button) specifically.
> So it doesn't mean that you need to break new tab in other cases to "fix"
> this particular case. In other words:
> that case is not a reason to break other cases you haven't mentioned. I hope
> it explains my comment.

I have no idea what other cases you mean.

> > Options used to be a dialog, so logically there was no way how it could replace a new tab.
> > It's a page now so things are different.
> Yeah, so the bug appeared. "Don't mess with user tabs" was behavior for
> ages, so users never expected that.

The "bug" has been there before for e.g. about:addons and for the URL bar's switch-to-tab feature.

> I mentioned this to show that your point
> about user expecting new tab to be closed (and deleted from tab history) is
> not valid.

No, you haven't shown that. You've said that your expectation is different and I believe you, but that doesn't automatically translate to the whole user base.

> Also, earlier you "felt like reusing the new tab will more often
> match
> the user's intention", but now (apparently) you don't, as you removed that
> mechanism. It gives me hope

I do think the behavior makes less sense for customize mode, yes.

> > we're getting off-topic. There's a bug on file for this somewhere.
> It's part of bug 1276125; I don't know how to move discussion to that bug

It's bug 776167.

Comment 12

[arni2033]

I was wrong when I started discussing irrelevant things in this bug. Sorry for spam.

Comment 13

[Justin Dolske [:Dolske]]

(In reply to Dão Gottwald [:dao] from comment #7)

> (B) is the "regression" because customize mode isn't even a page, it just
> uses a tab as a placeholder. It doesn't really feel like a page either,
> since you can't navigate in that tab. We could implement A's behavior for
> this but it's not going to be a priority.

This seems reasonable to me, fair to leave the bug open but I don't think it needs to be tracked as a significant regression.

Comment 14

[Tana Kimmet]

Attachment: same problem

Thanks from meticosgre1972.