Closed Bug 197123 Opened 17 years ago Closed 10 years ago
review inefficiency of column-width dragging behavior
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.
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 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.
(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/
Confirming. Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b4) Gecko/20050918 SeaMonkey/1.0a
Status: UNCONFIRMED → NEW
Ever confirmed: true
Still a problem in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) 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: download → nobody
Component: Download & File Handling → XUL Widgets
OS: Windows XP → All
Product: SeaMonkey → Toolkit
QA Contact: xul.widgets
Hardware: PC → All
Like this, maybe?
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Attachment #392004 - Flags: review?(enndeakin)
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.
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.
Neil, could you look at this again?
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.
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+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
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.