Closed Bug 332874 Opened 18 years ago Closed 18 years ago

Error: gContextMenu.menu has no properties when switching tabs

Categories

(SeaMonkey :: UI Design, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mcsmurf, Assigned: neil)

References

()

Details

(Keywords: fixed-seamonkey1.1a, fixed1.8.0.5, Whiteboard: [fixed-seamonkey1.0.3 verified-seamonkey1.1a])

Attachments

(2 files)

Lately (probably a regression) i get this error in the JS console when trying to switch from one tab to another (after using this browser window for a while):
Error: gContextMenu.menu has no properties
Source File: chrome://navigator/content/nsBrowserStatusHandler.js
Line: 261
This prevents the URL from being updated to the one from the other tab, also the Back/Forward buttons state does not get updated anymore and other things are broken, too. A new browser window works fine again.
(In reply to comment #0)
> Lately (probably a regression) i get this error in the JS console when trying
> to switch from one tab to another (after using this browser window for a
> while):
> Error: gContextMenu.menu has no properties
> Source File: chrome://navigator/content/nsBrowserStatusHandler.js
> Line: 261

I can reproduce this. Its look like the optimoz 'mouse gestures' from: http://optimoz.mozdev.org/gestures/index.html are 'activate' this bug on my system. A fresh profile in my Tinderbox SM 2006041504 has no problem. Do I install the mouse gestures, the bug appears.

BTW: my OS is Windows XP
Frank, could it be an extension that causes this for you?
No, i do not have any extensions installed (at least not at the time i saw that bug). When i have one installed so, it's Enigmail (and that one should not have any effect on the browser).
I could just null-check gContextMenu.menu and hope the problem goes away.
Better steps to reproduce would be appreciated. I'm a bit hesitant to wall-paper over this with a null check.
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a2) Gecko/20060518 SeaMonkey/1.1a] (nightly) (W98SE)

Confirming with SeaMonkey from 1.8.1 branch.

I discovered this bug with the testcase from bug 282180 attachment 222568 [details]:
1. Load that simple XUL page in a new tab.
2. (Right-)Click for context-menu anywhere on the page (on blank space or over a button).
2r: (no feedback, except when "hover" a button)
3. Close the tab
3r: Get the error !

Then, the error will happen again at each opening/closing of tab ... until you do ask and get a context-menu from a page.

NB: I don't know what is the expected behaviour at step 2r, in both cases (blank or hover_button)...


[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a2) Gecko/20060517 BonEcho/2.0a2] (nightly) (W98SE)

FWIW, FireFox from 1.8.1 branch does not have this bug.
Attached patch Proposed patchSplinter Review
Assignee: jag → neil
Status: NEW → ASSIGNED
Attached patch Alternate patchSplinter Review
(In reply to comment #7)
> Created an attachment (id=222604) [edit]
> Proposed patch

(I would select this one to request review on...)
(In reply to comment #9)
> (In reply to comment #7)
> > Created an attachment (id=222604) [edit]
> > Proposed patch
> 
> (I would select this one to request review on...)

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a2) Gecko/20060518 SeaMonkey/1.1a] (nightly) (W98SE)

Forgot to say:
*Either patch fixes the error with my testcase.
*(This patch is closer to FF and TB which do not have the xulNS check.)
I'm seeing this with the SeaMonkey 1.0.2 candidate, and I believe I saw the same problem earlier today, although I didn't check the JavaScript console when the Back and Forward buttons state was not updating properly before. I'm hoping it's not too late to get this fixed in 1.0.2.
Flags: blocking-seamonkey1.0.2?
In contentAreaContextOverlay.xul, replace the onpopupshowing near line 62 with:

           onpopupshowing="if (event.target != this) return true; gContextMenu =
 new nsContextMenu( this ); try { return gContextMenu.shouldDisplay; } finally {
 if (!gContextMenu.shouldDisplay) gContextMenu = null; }"

I think we should set gContextMenu to null if shouldDisplay is false. The try/finally to accomplish that was Neil's idea. In addition to this change, we'll need to do null checks in |function initEditorContextMenuItems(aEvent)| and |function initMailContextMenuItems(aEvent)|, or do something so these event listeners don't get called.
(In reply to comment #12)
>do something so these event listeners don't get called.
Does event.stopPropagation() work?

Alternative coding that might work:
if (event.target == this) {
  gContextMenu = new nsContextMenu(this);
  if (!gContextMenu.shouldDisplay) {
    event.preventDefault();
    event.stopPropagation();
    gContextMenu = null;
  }
}
Nope, that doesn't do the trick. I can't find any way to prevent an event from being delivered to listeners at the same level. I guess we could hook this code up at the popup's parent for the capture phase and then call stopPropagation(), but I think I'd prefer to just do the null checks in the other two listeners.
This didn't make 1.0.2, so I'm requesting that it block 1.0.3. I've now seen the problem happen a third time, so it looks like a fairly common problem.
Flags: blocking-seamonkey1.0.3?
Comment on attachment 222604 [details] [diff] [review]
Proposed patch

Serge isn't quite right; the firefox version of the shouldDisplay code got moved into setTarget but either way they set this.menu first.
Attachment #222604 - Flags: superreview?(jag)
Attachment #222604 - Flags: review?(jag)
(In reply to comment #16)
> (From update of attachment 222604 [details] [diff] [review] [edit])
> Serge isn't quite right; the firefox version of the shouldDisplay code got
> moved into setTarget but either way they set this.menu first.

Well, if I did not go and search the xulNS check code elsewhere, I simply said I prefered this patch too ;-)
Comment on attachment 222604 [details] [diff] [review]
Proposed patch

Fair enough, though I think we should also do my suggested change.
Attachment #222604 - Flags: superreview?(jag)
Attachment #222604 - Flags: superreview+
Attachment #222604 - Flags: review?(jag)
Attachment #222604 - Flags: review+
Attachment #222604 - Flags: approval-seamonkey1.1a?
Attachment #222604 - Flags: approval-seamonkey1.0.3?
Comment on attachment 222604 [details] [diff] [review]
Proposed patch

a=me for both branches (a Council member requesting counts as the first a= for 1.0.x)
Attachment #222604 - Flags: approval-seamonkey1.1a?
Attachment #222604 - Flags: approval-seamonkey1.1a+
Attachment #222604 - Flags: approval-seamonkey1.0.3?
Attachment #222604 - Flags: approval-seamonkey1.0.3+
Fix checked in.
Blocks: 329521
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: fixed-seamonkey1.0.3
1.0.2 is gone, and no need to mark as blocking for 1.0.3 as it's checked in already there
Flags: blocking-seamonkey1.0.3?
Flags: blocking-seamonkey1.0.2?
Flags: blocking-seamonkey1.0.2-
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3) Gecko/20060603 SeaMonkey/1.1a] (nightly) (W98SE)

V.Fixed on MOZILLA_1_8_BRANCH.
Whiteboard: fixed-seamonkey1.0.3 → [fixed-seamonkey1.0.3 verified-seamonkey1.1a]
(In reply to comment #20)

> Fix checked in.

WFM in my Trunk-SM 2006060301

Thanks to all for fixing this bug.
*** Bug 340732 has been marked as a duplicate of this bug. ***
Keywords: fixed1.8.0.5
You need to log in before you can comment on or make changes to this bug.