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)
SeaMonkey
Download & File Handling
Tracking
(Not tracked)
mozilla1.0.1
People
(Reporter: mikepinkerton, Assigned: bugzilla)
References
Details
(Keywords: platform-parity, Whiteboard: [adt2 rtm],custrtm-)
Attachments
(1 file, 4 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•23 years ago
|
Keywords: mozilla1.0,
nsbeta1
Comment 2•23 years ago
|
||
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
Assignee | ||
Comment 3•23 years ago
|
||
do you know how other non-modal windows without menubars do it?
Reporter | ||
Comment 4•23 years ago
|
||
non-modals w/out a menubar don't work. let's not create another one.
Assignee | ||
Comment 5•23 years ago
|
||
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?
Comment 6•23 years ago
|
||
Just to clarify, it only doesn't work when there are no other mozilla windows open.
Reporter | ||
Comment 7•23 years ago
|
||
not true. it doesn't work when it's the frontmost window
Reporter | ||
Comment 8•23 years ago
|
||
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.
Comment 9•23 years ago
|
||
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
Updated•23 years ago
|
Component: XP Apps: GUI Features → Download Manager
Comment 10•23 years ago
|
||
Shouldn't this be part of the Menu spec, therefore scheduled work?
Comment 11•23 years ago
|
||
nsbeta1+/adt3 per nav triage team
Comment 12•23 years ago
|
||
Adding attachment showing typical case, can be much further away.
Comment 13•23 years ago
|
||
Um, is that screen shot really for this bug?
Comment 14•23 years ago
|
||
Not at all, sorry, and thanks for catching my screwup.
Comment 15•23 years ago
|
||
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
Comment 16•23 years ago
|
||
*** Bug 138281 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 17•22 years ago
|
||
this is a pretty serious problem, especially if d/l manager always comes up.
Whiteboard: [adt3] → [adt2]
Comment 18•22 years ago
|
||
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?
Assignee | ||
Comment 19•22 years ago
|
||
*** Bug 132109 has been marked as a duplicate of this bug. ***
Comment 20•22 years ago
|
||
Since Bug 132109 has been marked as duplicate, changing Platform to All.
Hardware: Macintosh → All
Comment 21•22 years ago
|
||
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?
Assignee | ||
Comment 22•22 years ago
|
||
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).
Comment 23•22 years ago
|
||
blake, please fix this on all platforms or reopen bug 132109
Assignee | ||
Comment 24•22 years ago
|
||
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.
Comment 25•22 years ago
|
||
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
Comment 26•22 years ago
|
||
Is this part of the menu spec?
Comment 27•22 years ago
|
||
Blake, could you please just add whatever minimal menubar is easy on Mac only?
Whiteboard: [adt2] → [adt2 rtm]
Assignee | ||
Comment 28•22 years ago
|
||
Yes, per pink I have just added the navigator menubar on mac only.
Assignee | ||
Comment 29•22 years ago
|
||
Attachment #76861 -
Attachment is obsolete: true
Assignee | ||
Comment 30•22 years ago
|
||
I tested that this works on Windows by doing a little build foo, but it needs
genuine testing on a mac.
Comment 31•22 years ago
|
||
I'll test this out on mac and review if it looks good.
Comment 32•22 years ago
|
||
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.
Comment 33•22 years ago
|
||
Attachment #85609 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #87135 -
Flags: review+
Comment 34•22 years ago
|
||
Comment on attachment 87135 [details] [diff] [review]
patch w/ build changes
r=bryner for the changes in blake's original patch.
Assignee | ||
Comment 35•22 years ago
|
||
r/sr=blake on those build changes
Comment 36•22 years ago
|
||
Attachment #87135 -
Flags: superreview+
Assignee | ||
Updated•22 years ago
|
Whiteboard: [adt2 rtm],custrtm- → [adt2 rtm],custrtm- [eta 6/14/02]
Assignee | ||
Comment 37•22 years ago
|
||
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-
Comment 38•22 years ago
|
||
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)
Comment 39•22 years ago
|
||
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.
Assignee | ||
Comment 40•22 years ago
|
||
dprice, cls says you might be a good person to review bryner's patch. Can you
take a look?
Comment 41•22 years ago
|
||
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 42•22 years ago
|
||
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+
Updated•22 years ago
|
Attachment #88764 -
Flags: superreview+
Comment 43•22 years ago
|
||
Comment on attachment 88764 [details] [diff] [review]
fix for add-chrome.pl
sr=dveditz for the script change
Attachment #88764 -
Flags: superreview+
Assignee | ||
Comment 44•22 years ago
|
||
Comment on attachment 88764 [details] [diff] [review]
fix for add-chrome.pl
r=blake
Attachment #88764 -
Flags: review+
Assignee | ||
Comment 45•22 years ago
|
||
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.0 → mozilla1.0.1
Resolution: --- → FIXED
Comment 46•22 years ago
|
||
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...
Comment 47•22 years ago
|
||
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.)
Comment 48•22 years ago
|
||
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 → ---
Assignee | ||
Comment 49•22 years ago
|
||
sairuh, can you set user_pref("javascript.options.showInConsole", true) and tell
me the js error?
Assignee | ||
Comment 50•22 years ago
|
||
Attachment #87135 -
Attachment is obsolete: true
Attachment #88764 -
Attachment is obsolete: true
Comment 51•22 years ago
|
||
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
Comment 53•22 years ago
|
||
*** Bug 163356 has been marked as a duplicate of this bug. ***
Comment 54•22 years ago
|
||
But 155426 is related
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 56•22 years ago
|
||
*** Bug 174918 has been marked as a duplicate of this bug. ***
Comment 57•22 years ago
|
||
*** Bug 176741 has been marked as a duplicate of this bug. ***
Comment 58•22 years ago
|
||
*** Bug 176907 has been marked as a duplicate of this bug. ***
Comment 59•22 years ago
|
||
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.
Updated•22 years ago
|
Keywords: mozilla1.0.2
Comment 60•22 years ago
|
||
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.
Comment 61•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → DUPLICATE
Comment 62•22 years ago
|
||
*** Bug 188170 has been marked as a duplicate of this bug. ***
Comment 63•20 years ago
|
||
this isn't bug 155426, it's bug 21296
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 64•20 years ago
|
||
*** This bug has been marked as a duplicate of 21296 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•