Closed Bug 132027 Opened 23 years ago Closed 20 years ago

No menus work when download manager window has focus

Categories

(SeaMonkey :: Download & File Handling, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 21296
mozilla1.0.1

People

(Reporter: mikepinkerton, Assigned: bugzilla)

References

Details

(Keywords: platform-parity, Whiteboard: [adt2 rtm],custrtm-)

Attachments

(1 file, 4 obsolete files)

The D/L manager doesn't specify a menubar, so none of the menus on mac work when it is the frontmost window. this needs to be fixed.
--> download manager qa sairuh@netscape.com
QA Contact: paw → sairuh
Resummarizing to match the several similar blockers of the Usability for 1.0 tracker bug.
Blocks: 103711
Summary: Menus don't work when d/l manager is front window → No menus work when download manager window has focus
do you know how other non-modal windows without menubars do it?
non-modals w/out a menubar don't work. let's not create another one.
well, download manager doesn't need a menubar on win and linux. (marlon even suggested that the toolbar might be overkill, compared to MacIE's manager). So how about I show a menubar on mac only?
Just to clarify, it only doesn't work when there are no other mozilla windows open.
not true. it doesn't work when it's the frontmost window
here's the real deal: any command or menu which you'd previously accessed on the menubar that remains up will work. any new menu pulled down or command executed via cmd keys will not work.
mac/all, as i see this on 10.1.3. adding pp since it's mac-only.
Keywords: pp
OS: Mac System 9.x → All
Component: XP Apps: GUI Features → Download Manager
Shouldn't this be part of the Menu spec, therefore scheduled work?
nsbeta1+/adt3 per nav triage team
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3]
Target Milestone: --- → mozilla1.0
Attached image screen shot of typical case, can be much worse (obsolete) (deleted) —
Adding attachment showing typical case, can be much further away.
Um, is that screen shot really for this bug?
Not at all, sorry, and thanks for catching my screwup.
Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to target milestone 1.0.1. Please confine your attentions to driving down our list of TM 1.0 bugs for beta. Better to help, debug, or test one of them than fix one of these.
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 138281 has been marked as a duplicate of this bug. ***
this is a pretty serious problem, especially if d/l manager always comes up.
Whiteboard: [adt3] → [adt2]
well, interestingly, for me, Download Manager does not always come up. in fact, i have to select it explicitly from the Tools menu if i ever want to view it. under Mac OS X, with 1.0RC1 (Build ID: 2002041712), i only get the normal saving file dialog when i begin a download. when i reported a dupe of this bug, i was playing with the Download Manager just because it was a new feature, but i never see it unless i try to see it by explicitly opening it. what is the expected behavior of the Download Manager?
Depends on: 137440
*** Bug 132109 has been marked as a duplicate of this bug. ***
Since Bug 132109 has been marked as duplicate, changing Platform to All.
Hardware: Macintosh → All
Blake, any chance you are going to be able to fix this? If not, please reassign. If this isn't coming up by default, can we live with the problem for MachV?
Yes, I think this is pretty easy to fix. pink says to just use navigator's menus, so basically what we'd have to do is create a mac-only overlay with the navigator menubar. Not much work. However, I do think we can live with this if download manager doesn't come up by default (even if just on mac).
blake, please fix this on all platforms or reopen bug 132109
I don't see why the download manager needs a menubar on all platforms, especially not the navigator menubar, so bug 132109 should remain resolved anyway.
at least the Tools and Window menu should be available, so that you can open new navigator/mailnews/etc windows if only the download manager is open
Is this part of the menu spec?
Blake, could you please just add whatever minimal menubar is easy on Mac only?
Whiteboard: [adt2] → [adt2 rtm]
Yes, per pink I have just added the navigator menubar on mac only.
Whiteboard: [adt2 rtm] → [adt2 rtm],custrtm-
Attached patch patch (obsolete) (deleted) — Splinter Review
Attachment #76861 - Attachment is obsolete: true
Keywords: patch
I tested that this works on Windows by doing a little build foo, but it needs genuine testing on a mac.
I'll test this out on mac and review if it looks good.
The patch is missing the build stuff to hook it up to the CodeWarrior and Mach-O builds. Other than that, it seems to work fine. I'll post a new patch with the build changes.
Attached patch patch w/ build changes (obsolete) (deleted) — Splinter Review
Attachment #85609 - Attachment is obsolete: true
Attachment #87135 - Flags: review+
Comment on attachment 87135 [details] [diff] [review] patch w/ build changes r=bryner for the changes in blake's original patch.
r/sr=blake on those build changes
Whiteboard: [adt2 rtm],custrtm- → [adt2 rtm],custrtm- [eta 6/14/02]
If anyone's wondering, I haven't checked this patch in yet because bryner later reported that it causes a strange chrome registration problem, which I'm still investigating.
Whiteboard: [adt2 rtm],custrtm- [eta 6/14/02] → [adt2 rtm],custrtm-
cc'ing seawood... Chris, the patch here causes content,install,url,jar:resource:/chrome/comm.jar!/content/communicator/ to not be added to installed-chrome.txt, which hoses things pretty good. Any idea why? (This is on my mach-o build)
Attached patch fix for add-chrome.pl (obsolete) (deleted) — Splinter Review
The cause of the problem I mentioned seems to be that add-chrome.pl uses a regexp match (=~) to test whether a line is already in installed-chrome.txt. This means that if any line already in installed-chrome.txt contains as a substring the line it's trying to add, it won't get added. This just seems wrong. This patch makes it use "eq" to test for string equality.
dprice, cls says you might be a good person to review bryner's patch. Can you take a look?
A new mac-only chrome thing might conflict with what tao is doing in bug 144551 -- please coordinate with him. This looks like it's content-only, though, so it's probably oK Adding a new contents.rdf means adding new registerChrome() lines in the install scripts -- where are these?
Comment on attachment 88764 [details] [diff] [review] fix for add-chrome.pl eq is probably OK, although I believe contents.rdf was intended to live at the root of a movable chrome tree. The need for this change means you've got a contents.rdf living under another contents.rdf and I'm not sure that's right. Is there another way to solve this problem?
Attachment #88764 - Flags: superreview+
Attachment #88764 - Flags: superreview+
Comment on attachment 88764 [details] [diff] [review] fix for add-chrome.pl sr=dveditz for the script change
Attachment #88764 - Flags: superreview+
Comment on attachment 88764 [details] [diff] [review] fix for add-chrome.pl r=blake
Attachment #88764 - Flags: review+
Keywords: adt1.0.1
I checked this into the trunk for now. In the future, download manager will probably have its own dedicated menubar on all platforms. But we have to get trunk verification of this fix for it to go on the branch.
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: mozilla1.0mozilla1.0.1
Resolution: --- → FIXED
tested this with 2002.06.25.08 trunk comm bits on 10.1.5 and 9.1 (classic env), and saw two different behaviors: * 10.1.5: accessing commands from either menu or keyboard works fine. * 9.1: accessing commands from keyboard works, but they don't from the menu. spoke to blake about this who said it might be a makefile issue...
i partially take back what i said about keyboard cmds working on 10.1.5: strangely, cmd+W no longer closes the dl mgr window. this isn't a problem on the branch, nor was it a problem with my 6/20 trunk build. i'll grab y'day's trunk to see if it was broken then... (side note: oddly, cmd+W still works, ie closes the dl mgr with the mac 9.1 trunk build from today.)
just tested the 2002.06.24.08 trunk bits on 10.1.5, and closing windows (menu or keyboard) works. i fiddled around some more with today's (2002.06.25.08) trunk bits on 10.1.5, and it seems limited to the download mgr window. moreover, i cannot close it using either the menu or cmd+w. reopening --other windows don't appear affected (history, new nav window, tabs, bookmarks), just the download mgr. unless there was another checkin y'day which might caused this...?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
sairuh, can you set user_pref("javascript.options.showInConsole", true) and tell me the js error?
Attachment #87135 - Attachment is obsolete: true
Attachment #88764 - Attachment is obsolete: true
errors when i open the dl mgr window: Error: redeclaration of const nsIDOMWindowInternal Source File: chrome://communicator/content/tasksOverlay.js Line: 1 Error: redeclaration of const kIOServiceProgID Source File: chrome://communicator/content/utilityOverlay.js Line: 1 Error: redeclaration of const MOZ_HELP_URI Source File: chrome://help/content/contextHelp.js Line: 1 Error: gProxyButton has no properties Source File: chrome://navigator/content/navigator.js Line: 1658 Error: popup has no properties Source File: chrome://messenger/content/mailNavigatorOverlay.xul Line: 110 Error: this.bundle has no properties Source File: chrome://communicator/content/viewZoomOverlay.js Line: 49 errors when i attempt to close the window (1st one usine cmd+w, last two when using menu item): Error: win has no properties Source File: chrome://navigator/content/navigator.js Line: 1046 Error: _content has no properties Source File: chrome://navigator/content/navigator.js Line: 162 Error: win has no properties Source File: chrome://navigator/content/navigator.js Line: 1046
Removing adt1.0.1, as this has been reopened.
Keywords: adt1.0.1
*** Bug 163356 has been marked as a duplicate of this bug. ***
But 155426 is related
Bug 155426 is related
Blocks: 155426
QA Contact: sairuh → petersen
*** Bug 174918 has been marked as a duplicate of this bug. ***
*** Bug 176741 has been marked as a duplicate of this bug. ***
*** Bug 176907 has been marked as a duplicate of this bug. ***
I'm seeing this behavior on OSX 10.2.1 with 2002102908 with download status windows open, but the menus aren't working for me even if there are other windows open, if the download status window has focus, no menus work.
Keywords: mozilla1.0.2
i think bug 183420 is very similar (probably has the same cause and solution). please look into fixing it at the same time as this one. and, if this one is critical, that one should be also.
Duping to bug 155426, since the patch there fixes this (to some degree). *** This bug has been marked as a duplicate of 155426 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → DUPLICATE
*** Bug 188170 has been marked as a duplicate of this bug. ***
this isn't bug 155426, it's bug 21296
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** This bug has been marked as a duplicate of 21296 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago20 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: