Download Manager should have a menubar



17 years ago
10 years ago


(Reporter: Biesinger, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [fixedBeonex (py8ieh:recheck)][geekweb-fixed], URL)


(1 attachment)

Every other Mozilla window has a menubar, only the Download Manager misses one. 
This is bad because a) You can't start other components from the Download
Manager and b) it's inconsistent


17 years ago
OS: Linux → All
Hardware: PC → All

Comment 1

17 years ago
I agree.
I think this menu should be kinda like the JavaScript console menu bar (minimal
number of items). And I also think that there should be a menu for the currently
selected download containing all the elements suggested in bug 132019

Comment 2

17 years ago
adding self to cc list

Comment 3

17 years ago
Well I disagree, kind of. Right now its not possible, but I wish download
manager can appear in a tab. (way too many windows alread) If we do have menu
bar, that would look pretty rediclous. I wouldn't mind the menubar if an option
not to display it is offered.
Mike, eh, I suppose only very few users will want to do that... every Mozilla
window currently has a menubar which is not hidable, so why make an exception
for download manager?

Comment 5

17 years ago

*** This bug has been marked as a duplicate of 132027 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 7

17 years ago
Bug 132027 was resolved for the Mac only.  Should this xp bug be re-opened?
reopening, since bug 132027 is mac-only, and this is XP.

if you don't want this on all platforms, WONTFIX it, though bug 132027 comment
45 sounds like you do want that.
Resolution: DUPLICATE → ---
I'll work on this.

conversation between timeless and me about which menus should be present:
<timeless> i'd say file, edit, view, tools, window, help
<biesi> last three with obvious content...
<timeless> Edit could have delete, cut, copy, paste, perhaps reload, properties
and preferences
<biesi> Reload? What would that do?
<timeless> although you could argue that properties would go in file or view, i
don't care
<timeless> re<down>load
* biesi finds properties in Edit just fine
<timeless> ok
<timeless> view would probably do collumn choosing/sorting
<timeless> file might have very few items
<timeless> open would be one of them
<biesi> Open? What would that do? Add a new download or open a downloaded one?
<biesi> s/one/file/
* timeless notes that file>open and file>close wouldn't relate to eachother =o
<timeless> the open the selected item(s)
<timeless> file>new download
<timeless> i think that's all i can think of
<timeless> actually
<timeless> forget file>close
<timeless> file>hide
<timeless> erm file>hide download manager
<biesi> hm
<biesi> if that's even possible
<timeless> not your problem
<timeless> however i can tell you it will be
<biesi> "not my problem"? why do you think I asked?
<timeless> people complain about losing their downloads when they close the last
<timeless> so there's a bug talking about making the download manager
hide/minimize to tray instead of leaving 0 windows
<timeless> the actual activities that the last item in the menu do aren't really
significant to the person who makes the menus
<timeless> your last item will do the same thing as if someone clicks the [x]
Assignee: blaker → cbiesinger

Comment 10

17 years ago
re<down>load would go in the File menu, not Edit.  I would think that Properties
would go in File as well, but based on the Bookmarks window it would go in Edit.

Comment 11

17 years ago
> I would think that Properties would go in File as well, but based on the
> Bookmarks window it would go in Edit.

The Properties dialogue for bookmarks actually allows you to edit the bookmark.
This isn't the case for Download Manager files, so I think the Properties item
should be in the File menu (after all, it's giving you the properties of the
selected file).

CC'ing mpt because his Download Manager spec had a menu bar
looks like I'm going to implement mpt's spec
Priority: -- → P1
Target Milestone: --- → mozilla1.1beta

Comment 13

17 years ago
in explorer properties while you can't make many changes, you can make a few, 
in an ideal world, properties belong in the object menu which is not the edit 
menu. (In explorer, the object is a 'file', which is why things magically work 
-- in MacOSX the first menu for bookmarks could be 'Bookmark' and then you 
would have bookmark>properties [well, actually get info, but ...])

For now we just need to be consistent, even if we're consistently wrong.
timeless, I don't get your point. Are you suggesting renaming "File" to "Download"?
download properties require the disclosure widget. marking dependency.
Depends on: 85045
1.1b is out...
Target Milestone: mozilla1.1beta → mozilla1.2alpha
Created attachment 93924 [details] [diff] [review]

implements many, but far from all parts of mpt's spec
but it does implement a menubar with the most important features, which is what
this bug is about. I don't want to make the patch even larger.
Whiteboard: fixedBeonex
I have learned that UI patches are not wanted in this project. reassigning to
default owner.
Assignee: cbiesinger → blaker
Whiteboard: fixedBeonex → fixedBeonex (py8ieh:recheck)
As I understand it, the module owner only wants a fully fledged menu bar on Mac.
It would be nice if that had been mentioned when a patch was submitted, but...
biesi: You say that the patch does not implement the *whole* spec. Is it still
at a point that makes it somewhat "finished"?
Whiteboard: fixedBeonex (py8ieh:recheck) → fixedBeonex (py8ieh:recheck) [geekweb-P2]
um, I suppose. though it still doesn't implement resume support.
Whiteboard: fixedBeonex (py8ieh:recheck) [geekweb-P2] → [fixedBeonex (py8ieh:recheck)][geekweb-fixed]
QA Contact: sairuh → petersen
*** Bug 205802 has been marked as a duplicate of this bug. ***

Comment 23

15 years ago
Comment on attachment 93924 [details] [diff] [review]

>     key = "Mac";
>+    var propsLabel = bundle.getString("propertiesLabelMac");
>+    document.getElementById("menu_properties").setAttribute("label", propsLabel);
IMHO you should apply the showInShellLabel code to the properties menuitem.

>     case "cmd_showinshell":
>+    case "cmd_copy":
Putting this here makes the comment confusing.
>       // some apps like kazaa/morpheus let you "preview" in-progress downloads because
>       // that's possible for movies and music. for now, just disable indiscriminately.
>       return selectionCount == 1;

>     case "cmd_selectAll":
>-      return gDownloadView.view.rowCount != selectionCount;
>+      return gDownloadView.view.rowCount > 0;
What's with this change?

>     default:
>       return false;
>     }
>+    return false;
If this is to fix a spurious JS warning about not always returning a value then
I think that's been fixed if not then please remove the default clause.

>+    case "cmd_copy":
>+      if (navigator.platform.indexOf("Mac") != -1) {
>+        file = getFileForItem(getSelectedItem());
>+	gClipboardHelper.copyString(file.leafName);
>+      }
>+      else
>+        gClipboardHelper.copyString(getSelectedItem().id);
>+      break;
Does getFileForItem not work on the Mac?

>+    if (col.getAttribute("hidden") == "true")
if (col.hidden)

>+  var id = menuitem.getAttribute("id");
>+  id = id.substring(5, id.length);
var id =; will do here.

>+  if (theCol.getAttribute("hidden") == "true")
>+    theCol.removeAttribute("hidden");
>+  else
>+    theCol.setAttribute("hidden", "true");
The hidden attribute is persisted so removing the attribute won't work.
Use theCol.setAttribute("hidden", !theCol.hidden);

>-<?xul-overlay href="chrome://communicator/content/tasksOverlay.xul"?>
>+<?xul-overlay href="chrome://communicator/content/tasksOverlay.xul"?>

>+    <key id="key_stop" command="cmd_cancel" keycode="VK_ESCAPE"/>
>+    <!-- the key_stop_mac key will be enabled on mac only -->
>+    <key id="key_stop_mac" command="cmd_cancel" key="." modifiers="accel"/>
Perhaps it would be better to use the platformDialogOverlay to pull in these

>+function download() {
>+  window.opener.saveURL(urlField.value);
Would be nice to persist the value in a pref too.

>Index: resources/locale/en-US/downloadmanager.ent
.dtd, surely?
Product: Browser → Seamonkey

Comment 24

14 years ago
*** Bug 275569 has been marked as a duplicate of this bug. ***
Assignee: bross2 → download-manager
QA Contact: chrispetersen


10 years ago
Severity: minor → enhancement
Target Milestone: mozilla1.2alpha → Future

Comment 25

10 years ago
Fixed in SeaMonkey 2 supposedly by bug 472001.
Last Resolved: 17 years ago10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.