review inefficiency of column-width dragging behavior

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Toolkit
XUL Widgets
RESOLVED FIXED
15 years ago
7 years ago

People

(Reporter: Daniel B., Assigned: mstange)

Tracking

Trunk
mozilla1.9.3a1
Points:
---
Bug Flags:
wanted1.9.2 ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210

Although I originaly started writing this up a problem, please now consider this
as a request/reminder to review the current and alternative behaviors to figure 
out which is best for users.


In the download manager window's table header, the column-width dragging
behavior seems to be significantly less efficient for the user, frequently
requiring more dragging steps, than other common resizing behaviors.  

Consider trying to widen the first column and leave other column widths as
they are:

With Mozilla's behavior:
- In the table header, you drag the boundary between the first and second
  columns to the right.  That widens the first column.  However, it also narrows
  the second column.
- You drag the boundary between the second and third columns.  That fixes the
  second column, but changes the third column.
- You drag the boundary between the third and fourth columns.  That fixes the
  third column, but changes the fourth column.
- ...
- You continue until you've adjusted all column boundaries.

With "common behavior 1," (I don't have a name, but it's what Windows Explorer
uses in its Details view):

- You drag to widen the first column.  No other columns change their width; they
  just all shift to the right.  You're done.

Even if you want to narrow any non-adjacent column by the amount you widened an 
earlier column, the Mozilla behavior is more work for the user than usual:

In Mozilla:
- You drag to widen a column.  However, it also narrows the next column.
- You drag to fix that second column.  However, that narrows a third column.
- If you haven't reached the column you intend to narrow, you repeat.
- You're not done until you have reached the column you intended to narrow.

In "common behavior 1":

- You drag to widen a column.  No other columns change their width; those to the
  right just all shift to the right. 
- You drag to narrow a column.  No other columns change their width; those to
  the right just all shift back to the left, and you're done.

The only case in which the Mozilla behavior takes fewer steps is when you want
to move space between adjacent columns.  In that case, Mozilla takes one step; 
"common behavior 1" takes two.  

Thus, although Mozilla's behavior is better in one case (but only by one step), 
in many other cases its behavior is worse, and by multiple steps.

Of course, Mozilla's behavior does support stretching/shrinking to follow window
resizing, which "common behavior 1" does not support.

However, "common behavior 2" (proportional stretching/shrinking) supports window
resizing and still frequently takes fewer steps than Mozilla:
- You adjust one column.  All columns to the right stretch or shrink 
  proportionally.
- If you wanted that, you're done.
- If you wanted to take the space from or move the space to one other column,
  you adjust that column's start (so columns to the left are fixed) and end
  (so columns to the right are fixed).

As long as there are enough intervening columns, the current Mozilla behavior 
takes more steps.

[This is where I became less sure that a better alternative exists.  I _think_
the current behavior is not optimal, but I remember some non-intuitive or 
inefficient things with Netscape 4's attempted proportional behavior, so I don't
necessarily request that the current behavior be changed, but do request that
the design be reviewed sometime (after most other bugs).]


]




Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

13 years ago
Reporter do you still see this problem with the latest nightly, or even 1.7.3?
If not, this bug has probably been fixed and can be closed. Thanks.

If this bug is for Firefox, please change the "product" assignment for the bug
appropriately.
(Reporter)

Comment 2

13 years ago
> Reporter do you still see this problem with the latest nightly, or 
> even 1.7.3?

I still see it in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040616.  

I'll try to install 1.7.3 soon an report back on that.
Product: Browser → Seamonkey
(Reporter)

Comment 3

13 years ago
(In reply to comment #2)
> > Reporter do you still see this problem with the latest nightly, or 
> > even 1.7.3?

It still exists in 1.7.3.  
("Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910")

Also, note that it's not just the Download Manager window.  I see the same 
behavior in the Bookmark Manager window, the mail-reader window, and the
mail Search Messages window.

I presume that all tables with headers use the same UI control, so probably
all tables exhibit the same behavior.  (I haven't noticed any that behave
differently.)

> ... If not, this bug has probably been fixed and can be closed. 

Why did you think the but was probably fixed?  Did you have some trouble
reproducing or recognizing the reported behavior?  (Is my bug description 
missing some detail?)
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

12 years ago
Confirming.

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b4) Gecko/20050918 SeaMonkey/1.0a
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 6

11 years ago
Still a problem in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 SeaMonkey/1.0.6.

Come on, fix the GUI component.  Having to adjust every single column
boundary just to change one column's width SUCKS!
Severity: minor → normal
Summary: review (seeming) inefficiency of column-width dragging behavior → review inefficiency of column-width dragging behavior
Assignee: bross2 → download-manager
QA Contact: chrispetersen
(Assignee)

Updated

9 years ago
Assignee: download → nobody
Component: Download & File Handling → XUL Widgets
OS: Windows XP → All
Product: SeaMonkey → Toolkit
QA Contact: xul.widgets
Hardware: PC → All
(Assignee)

Comment 7

8 years ago
Created attachment 392004 [details] [diff] [review]
v1

Like this, maybe?
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Attachment #392004 - Flags: review?(enndeakin)

Comment 8

8 years ago
The patch here seems to just change the resizing to affect the last column rather than the next column.

I think the reporter is requesting that the tree columns stretch such that they take up more space horizontally in total, scrolling off the edge to the right. This is the behaviour of the file managers/pickers on the platforms we support.
(Assignee)

Comment 9

8 years ago
Yeah, that would be the best solution, but it seems that that's harder to implement.

Attachment 128196 [details] shows that resizeafter="grow" achieves the desired effect when the columns have a fixed width and no flex. However, setting resizeafter="grow" on the splitters of the tree in about:config, where the columns use flex, results in *really* strange resizing behaviour, with multiple columns resizing simultaneously... I suspect fixing that would require changes to nsSplitterFrame.
(Assignee)

Comment 10

8 years ago
Created attachment 392008 [details] [diff] [review]
v2: better patch, still the easy approach
Attachment #392004 - Attachment is obsolete: true
Attachment #392008 - Flags: review?(enndeakin)
Attachment #392004 - Flags: review?(enndeakin)
(Assignee)

Comment 11

8 years ago
Neil, could you look at this again?

Comment 12

8 years ago
It seems to me that which column gets resized is just a matter of preference, often different for different trees, or even for the same tree depending on what information one wants to see.

I think you'd really want a more thorough ui review to analyse which option is better, and, especially if there are more advantages to having the entire tree resize instead.
(Assignee)

Comment 13

8 years ago
Comment on attachment 392008 [details] [diff] [review]
v2: better patch, still the easy approach

Alex, what do you think about this? With this patch, making a column wider will make the rightmost column smaller, instead of the column right next to the resized column. That way you need less resize operations most of the time, as described in comment 0.

It would probably better if all the other columns stayed the same size and overflow would cause a horizontal scrollbar; but that's harder to implement.
Attachment #392008 - Flags: review?(enndeakin) → ui-review?(faaborg)
Comment on attachment 392008 [details] [diff] [review]
v2: better patch, still the easy approach

This is an improvement over our current behavior.  If we can get the entire area to increase in horizontal size, that would be ideal, and also match the behavior of the widget on Windows, OS X and Linux.
Attachment #392008 - Flags: ui-review?(faaborg) → ui-review+
(Assignee)

Updated

8 years ago
Attachment #392008 - Flags: review?(enndeakin)

Updated

8 years ago
Attachment #392008 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 15

8 years ago
http://hg.mozilla.org/mozilla-central/rev/586c0c651891
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1

Updated

8 years ago
Flags: wanted1.9.2?
Dear meandering Bugzilla reader,

The conversation about horizontal stretching (mentioned in comment 8 and comment 14) continues over in bug 647704.
You need to log in before you can comment on or make changes to this bug.