The following menu items should be disabled (greyed out) when there is no browser window open: File Save Page As... Send Link View Menu Enlarge Text Size Reduce Text Size Reload Show Images Stop Page Source Page Info Search Find on this page... Find again

QA Assigning to Sarah.

should this go to the XPApps folks instead...?

Let's try to fix this for beta 1 if we get a chance. Low priority tho' ...

not a priority, pushing out as far as possible.

Move to M21 target milestone.

Other components get around this by using the command updater, and Navigator doesn't use this at all... o_O Should look at this for the next release.

targetting mozilla/1.0, setting severity to normal.

This bug is a dup of 14180 although the comments here are more recent and this actually has a valid target MS so marking the other way around.

*** Bug 14180 has been marked as a duplicate of this bug. ***

nav triage team: Should fix this, marking nsbeta1, reassigning to pchen

We're past time to cut these low priority bugs from mozilla0.8. Please update these bugs today.

Talked to pinkerton about this, need to play with hiddenWindow.xul which controls the menubar when there are no windows on Mac. Sounds simple enough. ;-)

Although not a perfect dup, it's pretty much the same problem as 50877, just need to apply the fix to both view source and hidden window, and I just don't have the heart to nsbeta1- this one. *** This bug has been marked as a duplicate of 50877 ***

mass verification of duplicate bugs: to find all bugspam pertaining to this, set your search string to "DuplicateBugsBelongInZahadum". if you think this particular bug is *not* a duplicate, please provide a compelling reason, as well as check a recent *trunk* build (on the appropriate platform[s]), before reopening.

Bug 50877 was fixed by adding a menu bar to the view source window. This bug remained unfixed. Reopening.

*** Bug 107190 has been marked as a duplicate of this bug. ***

We need a new target milestone on this one.

->ben

minusing this until there's some traction (like a patch). I don't think we'd hold 1.0.1 for this, but, if an easy patch becomes available, please re-nominate.

Using FizzillaMach/2003-04-11-08-trunk, the following menu items are inappropriately shown with no windows open. File Edit View Close Other Tabs Find in This Page Show/Hide Save Page As Find Again Reload Send Page Find Previous Use Style Send Link Character Coding Print Preview Page Source Page Info Bookmarks Bookmark This Group of Tabs Reassigning to XP Toolkit/Widgets: Menus.

I'm working on this...

Apart from menuitems that should be disabled, there are a few menuitems that should work (but doesn't) when all windows are closed (not talking about Debug and QA menus), those are: - View --> Apply Theme --> Get New Themes - Go --> Home - Search the Web

This patch will also fix bug 114967, bug 83253 and parts of bug 130891. It will: 1) Disable inappropiate menuitems when all windows are closed. I have added id's to a few menuitems. I don't know if it's worth the extra lines to use a <command/> for Reload etc (for branch as well), but I could of course do it if someone insists (at least for Reload). 2) Fix the following js errors: Opening the bookmarks menu (updateGroupmarkCommand): Error: gBrowser has no properties Source File: chrome://navigator/content/navigator.js Line: 1017 (Since the menuitem now gets disabled by the js I removed it in the disabledItems array) Tools --> Popup Manager (createShowPopupsMenu): Error: getBrowser() has no properties Source File: chrome://navigator/content/navigator.js Line: 2427 3) Fix a few menuitems that should work when all windows are closed( "Go --> Home", "View --> Apply Theme --> Get New Themes" and "Tools --> Search the Web". This patch makes them work - mainly by using openTopWin instead of loadURI (I also needed a few more stringbundles etc). There are a few more things to fix, but I'll leave that for other bugs (Debug, QA menu and a js error from calling the updateGoMenu function (it's defined in sessionHistory.js...). We should also fix the Open Web Location dialog (open in current window/tab). Karsten, the patch applies on branch as well (some lines offset) if you prefer to test it on a branch build. I haven't used branch for testing, but when I wanted to see the Open Web Location sheet and verifying that theme switching worked I had to use a trunk build with the old toolkit :-(

(sorry for spam)

Comment on attachment 245032 [details] [diff] [review] Fix the major issues (when no windows are open) > var target = aEvent ? BookmarksUtils.getBrowserTargetFromEvent(aEvent) : "current"; >+ var browser = getBrowser(); >+ // Force target if we don't have a browser window open. >+ if (!browser) >+ target = "window"; > > if (homePage.length == 1) { > switch (target) { > case "current": > loadURI(homePage[0]); > break; > case "tab": > tab = gBrowser.addTab(homePage[0]); As this function already uses gBrowser, I don't see why you can't use it above, and then you could folder it into the ?: i.e. var target = gBrowser ? aEvent ? BookmarksUtils.getBrowserTargetFromEvent(aEvent) : "current" : "window"; or maybe you would prefer to reverse the tests: var target = !gBrowser ? "window": !aEvent ? "current" : BookmarksUtils.getBrowserTargetFromEvent(aEvent);

Comment on attachment 245032 [details] [diff] [review] Fix the major issues (when no windows are open) I'll update the patch with one of Neil's suggestions after it has been reviewed.

Note to self: this will also fix bug 83343.

(In reply to comment #27) > Note to self: this will also fix bug 83343. > and bug 147237

Comment on attachment 245032 [details] [diff] [review] Fix the major issues (when no windows are open) >Index: suite/browser/navigator.js >=================================================================== > function updateGroupmarkCommand() > { >- const disabled = gBrowser.browsers.length == 1; >+ const disabled = (!gBrowser || gBrowser.browsers.length == 1); > document.getElementById("Browser:AddGroupmarkAs") > .setAttribute("disabled", disabled); You probably may want to remove the disabled attribute instaed of setting it to false. r=me either way.

Updated patch (Used Neil's second suggestion from comment #25). Moving review flags.

Fix checked in by ajschult (thanks!).

Comment on attachment 245983 [details] [diff] [review] Updated patch This fixes some of the major issues when no windows are open on mac. I'd regard this as safe (and the patch have baked a few days on trunk as well).

Comment on attachment 245983 [details] [diff] [review] Updated patch first-a=me for SeaMonkey 1.1

1250 // Fallback if the stuff above fails: use the hard-coded search engine 1251 loadURI(gNavigatorRegionBundle.getString("otherSearchURL")); I forgot to change the loadURI call here - this patch does it :-/

Re-opening, need the last patch to go in before this is really fixed. Neil, can you check it in please?

Comment on attachment 245983 [details] [diff] [review] Updated patch I'll post a "real" branch patch.

Here's a diff against branch, including the follow-up patch. I consider this a quite important improvement for mac users - nearly all the issues in the menubar when no windows are opened are fixed now.

(In reply to comment #25) > (From update of attachment 245032 [details] [diff] [review] [edit]) > > var target = aEvent ? BookmarksUtils.getBrowserTargetFromEvent(aEvent) : "current"; > >+ var browser = getBrowser(); > >+ // Force target if we don't have a browser window open. > >+ if (!browser) > >+ target = "window"; > > > > if (homePage.length == 1) { > > switch (target) { > > case "current": > > loadURI(homePage[0]); > > break; > > case "tab": > > tab = gBrowser.addTab(homePage[0]); > As this function already uses gBrowser, I don't see why you can't use it above, > and then you could folder it into the ?: i.e. > var target = gBrowser ? aEvent ? > BookmarksUtils.getBrowserTargetFromEvent(aEvent) : "current" : "window"; > or maybe you would prefer to reverse the tests: > var target = !gBrowser ? "window": !aEvent ? "current" : > BookmarksUtils.getBrowserTargetFromEvent(aEvent); > Neil, Home now works from downloadmanager. This means that if you select Home when downloadmanager is open (and you have a browser window open) the homepage will load in a new browser window. Note that this is probably because I picked the second suggestion (the first suggestion would probably make a browserHome call from downloadmanager fail because DM doesn't know about BookmarksUtils). It's a little bit late to start thinking of a solution, though. Maybe check if window.location.href is hiddenWindow.xul?

Is bug 362055 related to this? If so, could some of you mac people resolve it accordingly? Thanks.

Comment on attachment 246705 [details] [diff] [review] Patch for branch first-a=me for 1.1; one more needed.

KaiRo, I don't know if CTho missed comment #33 (which is basically the same patch, except for the follow-up) or if he wanted another Council member's opinion.

Comment on attachment 246705 [details] [diff] [review] Patch for branch I think he missed that one ;-)

(In reply to comment #42) > (From update of attachment 246705 [details] [diff] [review] [edit]) > I think he missed that one ;-) Thanks :-)

Comment on attachment 246705 [details] [diff] [review] Patch for branch Landed this on MOZILLA_1_8_BRANCH.