If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Download progress window is too large [small screen]

RESOLVED EXPIRED

Status

SeaMonkey
UI Design
--
major
RESOLVED EXPIRED
16 years ago
8 years ago

People

(Reporter: Martyr, Assigned: jag (Peter Annema))

Tracking

Trunk
Future
PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
This is a real issue on laptops, especially the clamshell iBooks, generally any
laptop with a 14" screen or less. Screen real estate is at a premium here, and
the large download progress dialog boxes take up too much room.  

Steps to reproduce:
1) Download a file.
2) The resulting progress dialog box cannot be resized. 

Suggestions: Can't use double-click because it is a dialog box (not a window),
and resizing a d ialog box violates gui standards. How about just making it
smaller to begin with or allowing the size of the box to be tweakable or skinable?
download window -> File Handling 

I dunno if this bug is valid !
Why not minimize the window if you want more room ?
(we have an RFE about the download progress % in the title bar)
Assignee: asa → law
Component: Browser-General → File Handling
QA Contact: doronr → sairuh
It's a dialog.  You can't minimize dialogs on MacOS.  That's what the "can't use
double-click" part refers to, correct?

mpt? thoughts?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

16 years ago
Boris, you are correct. You CANNOT minimize or resize the dialog box on MacOS
9.x. On Windows, you can minimize. Can you do that on Linux? I don't want to
reccomend violating the Apple Human Interface guidelines (by making the dialogs
into windows), so shrinking their size seems to be the best thing to do.
You can minimize it on Linux, in most windomanagers....

I'll try to catch mpt (the UI Design default assignee) on IRC and ask him his
opinion.  He seems to not be reading bugzilla at the moment.

Comment 5

16 years ago
Unfortunately progress windows aren't implemented in XP Toolkit, so we fake 
them by using dialogs instead. If this bug was about progess windows being 
unminimizable, it would be a duplicate of bug 76110. However, it's not about 
that; it's about the progress windows being too large. That should hopefully be 
fixed with the implementation of the download manager, which should use 
document windows (not progress windows) to show information about selected 
downloads. See <http://mozilla.org/projects/ui/navigator/downloads/#info>.

[De-diagloging summary]
Summary: Download diaglogs are too large → Download progress window is too large
(Reporter)

Comment 6

16 years ago
Ok, thanks Matthew. Resolving that bug will address the concerns I raised here
-- multiple ways to skin the cat. However, 76110 is still marked future so it
doesn't look like this is to be fixed soon. We can close this one and increase
the priority of that one or shrink the size as mainly an aesthetics function.
It's that the default size does not work well with laptops...
could you pls attach a screenshot of what you're seeing? thx!

(Reporter)

Comment 8

16 years ago
Created attachment 69194 [details]
Relative size of dialog box to whole screen size on laptop.

Warning...120k.
thanks, mtulloch! yeah, taking up nearly 25%of your screen realestate...

another question, what is the resolution setting you have? or, moreover, d'you
experience this after increasing the resolution (if you're even able to)?
Summary: Download progress window is too large → Download progress window is too large [small screen]
(Reporter)

Comment 10

16 years ago
With the clamshell ibooks, max res. is 800x600...the screen size is I believe 13".

Comment 11

16 years ago
Next release, maybe.
Target Milestone: --- → Future

Comment 12

15 years ago
This is a better statement of what I meant in Bug #150744. (See also, Bug
#76110.) I use laptops most of the time, ranging from the sub-sized Powerbook
2400c (800x600) to the G3 2000 Pismo (1024x768). The current box layout is not
helpful to laptop users. This box can be made smaller by rearranging its text to
eliminate the present huge amount of wasted space in it. Too bad the box
apparently cannot be given a "minimize" widget to collapse it to the size of its
title bar if desired.  This is more than an aesthetics issue, IMO, and should be
addressed sooner than later to benefit us Mac users.
QA Contact: sairuh → petersen
(Reporter)

Comment 13

15 years ago
I'm satisfied with the Download manager that's present in the latest builds
(1.2beta, Mac OS 9.x). That essentially fixes the problem below. What do you
think, RogerW? I'm in favor of marking it "Fixed" or probably better "WorksForMe."

Except the old download window is still and option, and a lot of people still
use it... 

Of course if people don't care whether it's fixed...
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".
(Reporter)

Comment 16

14 years ago
Retargeted. It's a dialog in MacOS for laptops problem, regardless of whether
it's 9.x or OS X. The problem of wasted space and taking up too much screen real
estate remains. 
OS: Mac System 9.x → MacOS X
Assignee: law → jag
Component: File Handling → XP Apps
Product: Core → Mozilla Application Suite
QA Contact: chrispetersen

Comment 17

8 years ago
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
Status: NEW → UNCONFIRMED

Comment 18

8 years ago
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.