97617 - New windows should inherit toolbar visibility from current window

Status: RESOLVED INVALID

(SeaMonkey :: UI Design, defect)

Description

[Brett Denny]

Steps to reproduce:
   1. Open two browser windows, A and B, with any page containing links in each.  
   2. Make sure the toolbars in A are expanded and collapse all the toolbars in
window B.
   3. Right click on any link in window B and open the link in a new window.
   4. Now right click on a link in window A on a link and open it in a new window.

Expected Results:
   Windows should inherit the state of the toolbars from which they were opened.
 The window opened from B should have toolbars collapsed.  The window opened
from A should have toolbars expanded.  This is how Navigator 4.x worked.
Actual Results:
   Both new opened windows have toolbars collapsed.

Observations:
   It appears that the new window inherits not the state of the toolbars in the
current window, but rather the last action taked regarding collapsing or
expanding toolbars globally because following this pattern with multiple new
windows has the same effect.

Comment 1

[Chase Tingley]

Confirming, over to widgets

Comment 2

[Brett Denny]

Found this also applies to the sidebar.  I will try to file a new bug later today.

Comment 3

[Peter Trudelle]

I'm not sure I agree that the behavior you expect is best for all.  Typical
users might expect new windows to have default appearance (e.g., both subsequent
windows have toolbars), or  whatever appearance they last set, remembered by
sticky pref (e.g., neither have toolbar). IMO, both of these policies are
simpler, and yield more consistent and predictable behavior. I don't think there
is any widely-held, valid user model in which windows are 'children' of whatever
window happened to be active at the time they were created, and inherit
properties from them.  cc UE folks for input.

Comment 4

[Peter Trudelle]

resolving as invalid, current behavior is as expected.

Comment 5

[Matthew T (active 1999-2002)]

Reopening. The requested behavior is not only 4xp, it is also more predictable
than either of Trudelle's alternatives: it is much more obvious what the state
of the current window is than either (a) what the app's default is or (b) what
the setting was in whichever window you altered last (since you often won't
remember which window you altered last, if that window is even still open).

Comment 6

[Matthew T (active 1999-2002)]

--> XP Apps: GUI

Comment 7

[Peter Trudelle]

MPT: you have no right to reassign bugs you don't own, please leave mine alone.
 Taking back, and cc'ing UE for input once again. This may be 4xp, but that
doesn't make 4.x right. Current trunk behavior matches 6.0, 6.1, 6.2, 6.2.1 and IE.

Comment 8

[Lori Kaplan]

Although the current behavior is a little unpredictable in a test case (having
lots of browser windows open in different states), I believe that users collapse
toolbars to enlarge viewing space. Putting the browser in this state is
extremely useful on small screens, which defines the configuration of a large
part of our audience. Therefore I think preserving the implemented behavior
preserves the state most users have set their current browsers to. We shouldn't
change user settings without having a tremendous usability win for doing so.
That constitutes taking control from users which is a "bad idea" (see all
platform principles). Also, this behavior (opening windows with last set toolbar
state) is consistent with other window states we preserve based on last setting,
e.g. window size. Having the behaviors consistent across different states makes
the system more predictable (a "good thing", see platform principles). 

Comment 9

[Peter Trudelle]

->invalid

Comment 10

[Brett Denny]

*sigh*

Seeing as how I first filed this bug, I'd like to reopen it...  I agree with
MPT's comments - I find it much more predictable than the current implementation
and while it matches 6.0, 6.1, 6.2, 6.21, and IE, that doesn't make them right
either.  

Mr. Trudelle, while you say there is no valid user model of such "child windows"
I suggest that Nav4 (and previous version of Nav I believe) were as much of a
model as you could find.  Having been this way in previous versions of
Navigator, there must have been a reason and I do believe it was a good one - I
became very accustomed to this handling and I'm sure I'm not alone.  This new
way isn't working (for me).  Granted new users might adapt more to the current
implementation, (is there any valid user model for that either?) but what about
the old users?  

When I open a new window and change the toolbar state, it's usually because I'm
viewing an image or selection of text that is larger than the viewing area with
the toolbar's expanded.  If I want any new windows opened (usually from links
anyway), I can SEE what the state of the new window will be.  As it is now, I
have to remember what state I had them in 1, 2, 5, or 20 minutes ago.  I don't
recall *ever* having collapsed the toolbars and left them that way - that would
really interfere with my browsing experience.  Now that this has been changed
from previous Navigator versions, I am constantly (compared to before) having to
re-expand my toolbars.  

Is there to be no further discussion?  How about a pref - at least let me, the
user decide.  I apolgize for being so verbose, but I take great issue with this... 

Thanks,
Brett

Comment 11

[Peter Trudelle]

Brett, people can discuss this all they want in n.p.m.ui or n.p.m.browser (and
we have), but we have input from UE (Lori) that the implemented behavior is as
intended, so this bug is invalid.   If you'd prefer to call it an enhancement, I
could resolve it as wontfix, but you get the idea. We are aiming this at
millions of typical users, not at me or you.  I see no reason for making this a
pref; we don't want 'design by committee', where every decision is avoided by
creating a new pref, which requires more complexity, more code, more bloat, etc.