Build ID: 2000040815 When a page is finished loading or during any other time that the stop button on the toolbar and the Stop item on the View menu aren't enabled, the Stop item on the right click context menu should also not be enabled.

has nothing to do with xpmenus.

You obviously know more about this than I do, but I'm still a little confused... Why does this have nothing to do with XPMenus? I just checked the description: "For bugs in the cross-platform menu infrastructure, including the display and behavior of pop-up menus, pull-down menus, and context menus. " Perhaps XP Toolkit/Widgets: Menu isn't the best component for this bug, but seeing as how the Stop item in question is on the context menu, isn't this in some way related?

the XP Menus component is for bugs relating to behavior/functionality of the menus themselves, not the applications that can be accessed from them. if there are problems with the functionality of the accessed applications, those bugs go to their appropriate component. (eg, if a user couldn't access the Bookmarks editor from the Bookmarks menu, that'd be assigned to the Bookmarks component, rather than XP Menus.) i agree, this can be rather confusing! especially since it might not be obvious which component an application belongs to. (eg, XPApps is a huge bucket where cross-platform apps bugs go to, and can also be confusing by itself. ;-P) anyhow, since this deals with Stop not correctly behaving in the menu, it should still stay in XPApps (as opposed to Stop not working at all, which methinks would go to Networking...), but reassigned to radha.

Sairuh: I appreciate you clearing that up! I was unaware what specifically XPMenus related to, so your description really helped a lot :) In any event, does anyone know if this has been fixed in 2000041008? Having trouble reproducing it...

I haven't done anything regarding this. Bill, do you do anything regarding this, in the code that invokes the context menu.

I haven't done anything to it. My theory is that it probably was an "xp-something" regression (command dispatching thing) that has since cleared up.

not happening for me either anymore, verifying worksforme

this problem is back on latest win32 nightly...the Stop option of the right-click content context menu is still enabled at times when the page has finished loading, and it isn't enabled on the View menu. Reopening for now, I'll try to provide more details/insight/screenshot when I get home to my comp with Moz..

Move to M21 target milestone.

I sincerely disagree with the M21 marking on this...this definitely needs to make it into the commercial release. It's visible and noticeable, Stop on the content context menus is always enabled even if the View | Stop item isn't...

erm, disregard my last comment. I was confused that day and thought this was futured...

The Stop item on the context menu should become disabled depending on the state of canStop...however, canStop doesn't seem to be set anywhere (as are canGoForward and canGoBack). any ideas?

OK, I have a fix for this. It isn't right in the long-run, but that's only because we're currently doing things wrong anyways. The canStop broadcaster is busted, so the Stop item on the View menu is manually enabled and disabled. There's even a comment to that effect (http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigato r.js#336). But the item in the context menu doesn't work because it's observing canStop, which doesn't work. Attaching a patch to change that.

attached a patch, would appreciate if someone would review.

Subject to your own caveat that this isn't the right fix in the long run, that patch looks good (and it can't be harmful). However, being a lowly qa peon ... I haven't really figured out if r=jrgm is kosher :-] Two other points: 1) the stopContext shouldn't be set depending on if(!stopMenu). It should be done in its own test for existence. 2) You said 'the canStop broadcaster is broken'. Actually, I don't even see a <broadcaster id='canStop' ...> anywhere. Or is it that the back end is broken, so the broadcaster element was removed from the XUL.

Hey: (1) Oops! Missed that. Thanks -- i'll attach a new patch shortly. (2) Yeah, that's part of the problem -- the broadcaster doesn't even exist. I added it and tried some other modifications, but couldn't get it working. I think it's missing from some key backend point also (e.g. see http://lxr.mozilla.org/seamonkey/source/xpfe/browser/public/nsIBrowserInstance.i dl#37) Thanks.

Looks OK to me.

a=brendan@mozilla.org, but does + // XXX: Stop is determined in navigator.js; the canStop broadcaster is broken warrant a separate bug on file? /be

fix checked in. thanks john, brendan.

vrfy fixed on linux/mac/winnt using 2000.09.15.06/8/5 opt comm bits. Stop appears active while a page is still loading (tricky to do with a fast connection, but doable ;), and is then greyed-out when the page is done loading.