Inappropriate menu items show as enabled when no windows are open

RESOLVED FIXED in seamonkey1.1final

Status

SeaMonkey
UI Design
P1
normal
RESOLVED FIXED
18 years ago
11 years ago

People

(Reporter: kirbyt, Assigned: stefanh)

Tracking

({fixed-seamonkey1.1})

Trunk
seamonkey1.1final
PowerPC
Mac OS X
fixed-seamonkey1.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

18 years ago
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

Comment 1

18 years ago
QA Assigning to Sarah.
Component: UE/UI → XP Toolkit/Widgets: Menus
QA Contact: elig → sairuh
should this go to the XPApps folks instead...?
Assignee: shuang → don
Component: XP Toolkit/Widgets: Menus → XPApps

Comment 3

18 years ago
Let's try to fix this for beta 1 if we get a chance.  Low priority tho' ...
Assignee: don → ben
Target Milestone: M14
Status: NEW → ASSIGNED
not a priority, pushing out as far as possible.
Target Milestone: M14 → M20

Comment 5

17 years ago
Move to M21 target milestone.
Target Milestone: M20 → M21
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. 
Severity: minor → normal
Target Milestone: M21 → mozilla1.0

Comment 8

17 years ago
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.

Comment 9

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

Comment 10

17 years ago
nav triage team:

Should fix this, marking nsbeta1, reassigning to pchen
Assignee: ben → pchen
Status: ASSIGNED → NEW
Keywords: nsbeta1

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla0.8

Comment 11

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

Comment 12

17 years ago
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. ;-)

Comment 13

17 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → VERIFIED

Comment 15

15 years ago
Bug 50877 was fixed by adding a menu bar to the view source window. This bug
remained unfixed. Reopening.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

Comment 16

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

Comment 17

15 years ago
We need a new target milestone on this one.
Keywords: mozilla1.0.1
Summary: Inapropriate menu items show as enabled when no browser window is open → Inappropriate menu items show as enabled when no browser window is open

Comment 18

15 years ago
->ben
Assignee: pchen → ben
Status: REOPENED → NEW
Target Milestone: mozilla0.8 → ---

Comment 19

15 years ago
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.
Keywords: mozilla1.0.1 → mozilla1.0.1-

Updated

14 years ago
Blocks: 4252

Comment 20

14 years ago
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.
Assignee: ben → hyatt
Component: XP Apps → XP Toolkit/Widgets: Menus
OS: Mac System 8.6 → MacOS X
QA Contact: sairuh → shrir
Summary: Inappropriate menu items show as enabled when no browser window is open → Inappropriate menu items show as enabled when no windows are open
QA Contact: shrir → sairuh

Updated

13 years ago
Blocks: 261030
Assignee: hyatt → jag
Component: XP Toolkit/Widgets: Menus → XP Apps
Product: Core → Mozilla Application Suite
QA Contact: bugzilla
(Assignee)

Comment 21

11 years ago
I'm working on this...
Assignee: jag → stefanh
Priority: P3 → P1
Target Milestone: --- → seamonkey1.1final
(Assignee)

Comment 22

11 years ago
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
(Assignee)

Comment 23

11 years ago
Created attachment 245032 [details] [diff] [review]
Fix the major issues (when no windows are open)

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 :-(
Attachment #245032 - Flags: superreview?(neil)
Attachment #245032 - Flags: review?(mnyromyr)
(Assignee)

Comment 24

11 years ago
(sorry for spam)
Status: NEW → ASSIGNED

Comment 25

11 years ago
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);
Attachment #245032 - Flags: superreview?(neil) → superreview+
(Assignee)

Comment 26

11 years ago
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.
(Assignee)

Comment 27

11 years ago
Note to self: this will also fix bug 83343.
(Assignee)

Comment 28

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

Comment 29

11 years ago
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.
Attachment #245032 - Flags: review?(mnyromyr) → review+
(Assignee)

Comment 30

11 years ago
Created attachment 245983 [details] [diff] [review]
Updated patch

Updated patch (Used Neil's second suggestion from comment #25). Moving review flags.
Attachment #245032 - Attachment is obsolete: true
Attachment #245983 - Flags: superreview+
Attachment #245983 - Flags: review+
(Assignee)

Comment 31

11 years ago
Fix checked in by ajschult (thanks!).
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago11 years ago
Resolution: --- → FIXED
(Assignee)

Comment 32

11 years ago
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).
Attachment #245983 - Flags: approval-seamonkey1.1?

Comment 33

11 years ago
Comment on attachment 245983 [details] [diff] [review]
Updated patch

first-a=me for SeaMonkey 1.1
(Assignee)

Comment 34

11 years ago
Created attachment 246442 [details] [diff] [review]
Follow-up patch (use openTopWin on fallback as well)

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 :-/
Attachment #246442 - Flags: superreview?(neil)
Attachment #246442 - Flags: review?(neil)

Updated

11 years ago
Attachment #246442 - Flags: superreview?(neil)
Attachment #246442 - Flags: superreview+
Attachment #246442 - Flags: review?(neil)
Attachment #246442 - Flags: review+
(Assignee)

Updated

11 years ago
Whiteboard: [Checkin needed] of attachment #246442
(Assignee)

Comment 35

11 years ago
Re-opening, need the last patch to go in before this is  really fixed. Neil, can you check it in please?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

11 years ago
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Whiteboard: [Checkin needed] of attachment #246442
(Assignee)

Comment 36

11 years ago
Comment on attachment 245983 [details] [diff] [review]
Updated patch

I'll post a "real" branch patch.
Attachment #245983 - Flags: approval-seamonkey1.1?
(Assignee)

Comment 37

11 years ago
Created attachment 246705 [details] [diff] [review]
Patch for branch

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.
Attachment #246705 - Flags: approval-seamonkey1.1?
(Assignee)

Comment 38

11 years ago
(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?

Comment 39

11 years ago
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.
(Assignee)

Comment 41

11 years ago
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 42

11 years ago
Comment on attachment 246705 [details] [diff] [review]
Patch for branch

I think he missed that one ;-)
Attachment #246705 - Flags: approval-seamonkey1.1? → approval-seamonkey1.1+
(Assignee)

Comment 43

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

Thanks :-)
Whiteboard: [checkin needed] of attachment #246705 (1.8.1 branch)

Comment 44

11 years ago
Comment on attachment 246705 [details] [diff] [review]
Patch for branch

Landed this on MOZILLA_1_8_BRANCH.
(Assignee)

Updated

11 years ago
Keywords: fixed-seamonkey1.1
Whiteboard: [checkin needed] of attachment #246705 (1.8.1 branch)
You need to log in before you can comment on or make changes to this bug.