184660 - clicking "home" with home page defined as a group should start with current tab if it is blank

Status: RESOLVED WORKSFORME

(SeaMonkey :: Tabbed Browser, defect)

Description

[Olegario Craig]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203

If the home page is set to a group of 5 tabs, then clicking the "home" button
will open 5 new tabs in addition to the current setup. This is inconsistent with
the behavior that occurs when home is defined as a single page -- it opens in
the current tab. IMHO the first tab of a grouped home page should open in the
current tab; i.e. if the home page is defined as a set of N tabs, then clicking
"home" should open (N-1) new tabs, with the 0th page loading in the current tab.
I believe the UI leads a user to expect that when clicking a bookmark or the
home button, the contents will load into the current view; this behavior should
not change simply because the clicked entity is a set of items.

Reproducible: Always

Steps to Reproduce:
1. start mozilla
2. load a page (e.g. mozilla.org)
3. open another tab
4. in the second tab load a page (e.g. slashdot.org)
5. Edit->Preferences->Navigator, click "Use Current Group" and "When Navigator
starts up, display (*) Blank page
6. click OK, close mozilla
7. restart mozilla you should have a blank page
8. click "Home" button

Actual Results:  
mozilla displays three tabs: the first is a blank page, the second has
mozilla.org loaded, the third has slashdot loaded

Expected Results:  
mozilla should display two tabs;  the first should contain mozilla.org, the
second should contain slashdot.org.

Please don't get me wrong -- I *love* the "define home page as a group" feature.
However, I think the UI should be consistent, and I think that the expected
behavior upon clicking a bookmark or the home icon is that the requested entity
begins loading in the current view (or tab) and this should not change merely
because the requested item is a group of other items.

Comment 1

[Jason Bassford]

If you want this for the Home page but *NOT* for group bookmarks in general then
this is a separate bug.  However, if you feel that all group bookmarks
(including Home pages defined as multiple tabs) should not leave a "blank" tab
then this is really a dupe of bug 159104.

Comment 2

[Jason Bassford]

On second thought, it's not a dupe at all - but it is complimentary.  Bug 159104
deals with overwriting a single tab if that tab is blank or the (single tab)
Home page.

This bug deals with overwriting a single tab, *regardless* of its content, if
the Home button is clicked.

-> Confirming as new.

Comment 3

[Olegario Craig]

> This bug deals with overwriting a single tab, *regardless* of its content, if
> the Home button is clicked

Yes, but... Hmm. That's not all.

Having poked around a bit more in the crossreffed bugs (which I presume I would
have found had I removed "home" from the search terms before entering this bug)
I guess that my end desires most closely match those of Ian Hickson as expressed
in comments 20/21 of bug 153016. To wit:

Opening a group bookmark OR clicking the home icon should:
- load the first bookmark item in the currently-focused tab, pushing the current
tab contents into that tab's history.
- insert other bookmark items in new tabs directly to the right of the
currently-focused tab, or at the very least append them to rightmost tab.

So I guess this bug could be marked as a dupe of 153016. 

Having read that bug's current comments, I understand the conflict between
"insert new tabs rightwards of current focus" and "inserting tabs is bad because
it disturbs the order the user expected". My suggestion for a resolution to this
 dilemma is that the new tabs should be inserted rather than appended, but they
should be given a different color until one of them is focused. 

Comment 4

[Jason Bassford]

No, it shouldn't be marked a dupe of bug 153016.  I know that you're the
reporter of this bug (so I shouldn't be telling you what you mean here), but
what you've just said you want in comment 3 is quite different from the original
Summary and what you'd said in comment 0 referred to.  I confirmed the bug as
new based on the original intent - I don't think it should be morphed into
something else at this point.  (Particularly since I have an interest in keeping
a bug of that original intent in play.)

Dealing with what happens with tab groups or a Home setting of multiple tabs
when the current browser has MORE than one tab is, as you say, already addressed
by other bugs.

But I like having a bug in existence (currently this one comes closest) that
dealing with what happens with a multiple tab Home setting on top of a single
tab that's open.  I don't mean to "usurp" your own bug, but rather than morphing
this and then, necessarily, marking it a dupe, I'd rather keep it open.  (You
can just follow bug 153016 if you wish.)

Comment 5

[Olegario Craig]

Fair enough. I just saw it as a subset of the 153016 case, and figured it'd ease
bug manglement^Wmanagement to mark it as such. I have no quarrel with treating
it as a separate issue if that makes someone else life easier and/or more logical.

Thanks.

Comment 6

[Jason Bassford]

With the fix for bug 203960, I still wouldn't "technically" call this one fixed,
but I'd have no problem resolving it as such if the reporter is okay with that.
 (Stance from comment 3. <grin>)  I'm now at the mental point where
simplification/consolidation of these bugs is easiest - especially since there's
only a limited time before Seamonkey is abandoned to Firebird, and it makes
sense to decrease the number of open bugs before then so that attention can be
more focused.

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[:Hb]

> 5. Edit->Preferences->Navigator, click "Use Current Group" and "When Navigator
starts up, display (*) Blank page

This option is gone from SM2, so WFM. See bug 159104 for same problem in new window.