Last Comment Bug 552970 - download progress dialog doesn't remember position / coordinates
: download progress dialog doesn't remember position / coordinates
Status: RESOLVED FIXED
: fixed-seamonkey2.0.5
Product: SeaMonkey
Classification: Client Software
Component: Download & File Handling (show other bugs)
: unspecified
: All All
: -- minor (vote)
: seamonkey2.1a1
Assigned To: Justin Wood (:Callek)
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-17 09:13 PDT by Martin F.
Modified: 2010-04-01 21:18 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
v1.0 -- use persist (496 bytes, patch)
2010-03-17 11:36 PDT, Justin Wood (:Callek)
no flags Details | Diff | Splinter Review
v2 -- just screenx and screeny (474 bytes, patch)
2010-03-17 17:46 PDT, Justin Wood (:Callek)
neil: review+
neil: superreview+
kairo: approval‑seamonkey2.0.5+
Details | Diff | Splinter Review

Description Martin F. 2010-03-17 09:13:14 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.8) Gecko/20100205 Lightning/1.0b1 SeaMonkey/2.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.8) Gecko/20100205 Lightning/1.0b1 SeaMonkey/2.0.3

The download progress dialog doesn't seem to remember its position/coordinates, when being moved on the screen. On the next download it's centered again, which is pretting annoying when performing a dozen downloads a day.

This is a regression compared to SM1.x if I'n not mistaken.

Reproducible: Always

Steps to Reproduce:
1. Download a file from the web
2. Move the progress dialog to other coordinates.
3. Download another file
Actual Results:  
Next progess window appears centered again.

Expected Results:  
Progress dialog opens with coordinates of last used position.
Comment 1 Justin Wood (:Callek) 2010-03-17 11:36:24 PDT
Created attachment 433108 [details] [diff] [review]
v1.0 -- use persist

In my (very limited) testing of SM 1.1.7 with regard to this, it does not appear to be a regression.

However it does appear (easily) fixable.

This patch should do it.
Comment 2 neil@parkwaycc.co.uk 2010-03-17 14:31:55 PDT
Comment on attachment 433108 [details] [diff] [review]
v1.0 -- use persist

I don't think we want to persist all of these.
Comment 3 Martin F. 2010-03-17 16:23:13 PDT
May I ask what "sizemode" stands for?
Comment 4 Robert Kaiser 2010-03-17 16:47:08 PDT
(In reply to comment #3)
> May I ask what "sizemode" stands for?

https://developer.mozilla.org/en/XUL:Attribute:sizemode
Comment 5 Justin Wood (:Callek) 2010-03-17 16:48:51 PDT
(In reply to comment #2)
> (From update of attachment 433108 [details] [diff] [review])
> I don't think we want to persist all of these.

Order of priority for this bug, for the persists:

1) ScreenX, ScreenY <--- Per Summary
2) Width, Height    <--- I think also worth it
3) Sizemode         <--- I was less certain to even include it.

(In reply to comment #3)
> May I ask what "sizemode" stands for?

Sure, its basically, maximized vs positioned/windowed.
Comment 6 Justin Wood (:Callek) 2010-03-17 17:46:06 PDT
Created attachment 433217 [details] [diff] [review]
v2 -- just screenx and screeny
Comment 7 Justin Wood (:Callek) 2010-03-19 19:47:55 PDT
Pushed as http://hg.mozilla.org/comm-central/efae333beb46
Comment 8 Justin Wood (:Callek) 2010-03-19 19:49:17 PDT
Comment on attachment 433217 [details] [diff] [review]
v2 -- just screenx and screeny

Low-Risk, actually would make this work better for some 2.0 users.
Comment 9 Robert Kaiser 2010-03-20 04:37:20 PDT
Comment on attachment 433217 [details] [diff] [review]
v2 -- just screenx and screeny

It's a functionality change, and I'm a bit reluctant to allow those on a stable branch, but it's so simple, so let's just do it.
Comment 10 Justin Wood (:Callek) 2010-04-01 21:18:06 PDT
Heh, slipped through my todo-cracks:
Pushed as: http://hg.mozilla.org/releases/comm-1.9.1/rev/9b39f09b7ccd

Note You need to log in before you can comment on or make changes to this bug.