Open Bug 166059 Opened 22 years ago Updated 15 years ago

Download Manager: status bar content is wrong after unselecting all but 1 item of a multi-selection

Categories

(SeaMonkey :: Download & File Handling, defect)

Product:
SeaMonkey
Component:
Download & File Handling
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

People

(Reporter: sgautherie, Unassigned)

References

Details

(Whiteboard: [ToDo: comment 21]) 

I use "Save As" in the Browser;
The Download Manager opens;

After download is completed,
I highlight an entry, then remove it, by keyboard ou menu button;
after deletion, there is no visible focus anymore;

I can do other deletions ... it works, but I don't see anymore what I am doing.
Serge, what build are you using?  Always include the build ID in bug reports you
submit (the build ID is in the Mozilla titlebar) also in this case the theme
being used might be helpful.  

I cannot reproduce this problem (Linux build: 2002090822).  For me the next item
in the list is always highlighted (in a slightly lighter colour using the Modern
theme).  

The only exception to this is when deleting the *last* line in the download
manager list.  In this case no line is left focused.  
I'm using "Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.1) Gecko/20020826";
with "Classic" theme.

I checked and agree with your description:
*first (after each D.M. opening), the highlight is "dark blue", as expected.
*then (after a deletion), the highlight remains "light grey" ... which is the
color which I use for my background (but for this checking) :->
*If I delete the last line, the focus is actually lost, even if there are others
lines above.


PS:
*For "Classic" theme, I get it by "default" when I install (which is fine for
me): I chose it once instead of Modern, and now W95 seems to remember that even
so I do some cleanup between install...
*For "build ID", I once used a bug report form which asked for many details
(like buildID), but <http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser>
does not, so I wondered if it would "remember" it or... :-(

(Then, you could change Severity to Minor...)
Refocusing this bug to reflect when focus is really lost and marking as NEW (no
existing bug found).  

Serge, the bugzilla form asking lots of questions is the bugzilla helper form
and is definitely recommended when entering bugs.  It can be found at:
http://bugzilla.mozilla.org/enter_bug.cgi?format=guided
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 95 → All
Hardware: PC → All
Summary: Focus is lost after removing an entry → Focus is lost after removing the last entry
With "Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910"

Same bug.

(Thanks for the advice.)
QA Contact: sairuh → petersen
"Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016"

Same as v1.2a and v1.1.

*** Bug 168726 has been marked as a duplicate of this bug. ***
Updated summary of this bug, after bug 168726 comment 4:

1) Most important is the loss of function (focus)
2) Then the visual effect (color)

For both, the workaround is to close and reopen D.M..
Summary: Focus is lost after removing the last entry → Focus is lost after removing the last entry; and color changes after the 1st remove of any other entry
"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2) Gecko/20021126"

The deletion of last entry is fixed: no loss of focus anymore :-)

The color change remains to be fixed :-<

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312]

Bug still there.

Now, I found bug 156489,
and mine (W95) seems to be a dupe of this other one (MacOS).

I let you verify this, and mark one of them as dupe of the other as needed.

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401]

Bug still there. (with v1.3 profile, at least)

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401]

***** a)

Not this/a bug, but maybe a (tiny) speed optimization !?

http://lxr.mozilla.org/seamonkey/source/xpfe/components/download-manager/resources/downloadmanager.js#274
[
- for (i = 0; i <= selectedItems.length - 1; ++i) {
+ for (i = selectedItems.length - 1; i >= 0; --i) {
    gDownloadManager.removeDownload(selectedItems[i].id);
  }
]

Do you agree ?
How to have it checked in ?

***** b)

The selection after remove happens correctly at
http://lxr.mozilla.org/seamonkey/source/xpfe/components/download-manager/resources/downloadmanager.js#288

But where is the 'highlight' color (not) set ?

***** c)

I found another bug:

1. Select (Ctrl-Click) 2 entry:
   -> the status bar is emptied/cleaned :-)
2. Unselect (Ctrl-Click) one of the selected entry:
   -> the status bar is updated with the path of the unselected entry.
   -> for consistency, it should be updated with the path of the remaining
selected item instead !!

This bug may(?) happen at
http://lxr.mozilla.org/seamonkey/source/xpfe/components/download-manager/resources/downloadmanager.js#126

Should I file another bug, or can we just say that this is a third issue of
"focus" behaviours dealt with in the current bug ?

Addition to comment 13 part C (status bar update bug):

C.1) Inside JS.D. (= Venkman), the file has 10 more lines in
'DLManagerStartup()', than in LXR.
And based on line 95 usefulness (or lake of), LXR version seems "odd".
Can you explain this situation ? Thanks (It's my first use of JS.D.).

NB: For the time being, I'll use LXR line numbers !

C.2) I verified that this bug happens at line 126, because of line 323, at which
'gDownloadView.currentIndex' points to the UNselected item !
(I assume that the current value of this "object" is the intended one. Isn't it ?)

As a test, changing the value of this "object" fixes this bug.

C.3a) I propose the following patch:
[
124   var selectionCount = gDownloadView.treeBoxObject.selection.count;
125   if (selectionCount == 1)
- 126     gStatusBar.label = getSelectedItem().id;
+         // NB: 'getSelectedItem()' cannot be used here, because it may point
to an unselected item when a multiple selection is reduced to one item only.
(see bug 166059)
+ 126     gStatusBar.label = getSelectedItems()[0].id;
127   else
128     gStatusBar.label = "";
]

C.3b) The whole file (and may be others ?) should be reviewed too for the same
issue at other lines !

Furthermore, could this be somehow related to bug 171890 ?
Summary: Focus is lost after removing the last entry; and color changes after the 1st remove of any other entry → Focus is lost after removing the last entry; and color changes after the first remove of any other entry
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401]

Addition to my comment 9 (and comment 13 part B):

The color bug is not specific to D.M.;
It happens also when removing cookie(s) in Cookie Manager !

Should a new bug report be filed, against a different component (like "XP
Toolkit/Widgets: Trees") ?
-> me
Assignee: blaker → varga
Priority: -- → P3
Target Milestone: --- → mozilla1.5beta
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030]
(BuildId=2003110115, bug 224340#c19) (W98SE)

Re comment 14:

Now, I am puzzled:

What happens in D.M. is that the last unselected item retains the focus,
and Launch and Show (:-(), or up/down arrows (:-)), will apply to it;
while Remove will apply to the remaining selected item !!

As a comparison, here is what happens in Window Explorer of W98SE:
The unselect item retains the focus too,
and F2 (rename), or up/down arrows, will apply to it;
but, Copy(+Paste) button, or Del key/button, will apply to the remaining
selected item !

Hints welcomed !

Addition to comment 17:

In Windows Explorer, the size of the remaining selected item is displayed in the
stauts bar;
whereas D.M. displays the name of the focused item.
Product: Browser → Seamonkey
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/2007052105 SeaMonkey/1.5a] (suiterunner, tinderbox-builds) (W2Ksp4)

Bug still there; at least the color change.
Summary: Focus is lost after removing the last entry; and color changes after the first remove of any other entry → Download Manager: Focus is lost after removing the last entry; and color changes after the first remove of any other entry
Serge, are you still seeing this with the new download manager in 2.0b1 or later?
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1] (release) (W2Ksp4)

To summarize:

First (focus) issue was "fixed" as of comment 9.

Second (color) issue is now fixed :-)

Third (status bar) issue is still there. (see comment 13 and comment 14)
This is even more obvious if you delete the unselected but focused entry:
after the entry is gone, its path remains in the status bar :-<
(I'm not sure where the new code lives...)
Assignee: Jan.Varga → nobody
Flags: wanted-seamonkey2?
Priority: P3 → --
QA Contact: chrispetersen → download
Whiteboard: [ToDo: comment 21]
Target Milestone: mozilla1.5beta → ---
Ah, so (in function onTreeSelect in downloadmanager.js) the status bar is reporting on the current index instead of the selected index.

Command handling is being fixed as part of multiselect handling.

removeDownload is probably not a problem, but could be fixed by checking whether the index was previously selected.
If you already needlessly request a wanted flag, could you at least correct the summary to be about what is really still the problem there?
Summary: Download Manager: Focus is lost after removing the last entry; and color changes after the first remove of any other entry → Download Manager: status bar content is wrong after unselecting all but 1 item of a multi-selection
I don't see any reason to give this special priority, but it's also not unwanted, so cancelling the wanted flag.
Flags: wanted-seamonkey2.0?
You need to log in before you can comment on or make changes to this bug.