Last Comment Bug 332874 - Error: gContextMenu.menu has no properties when switching tabs
: Error: gContextMenu.menu has no properties when switching tabs
Status: RESOLVED FIXED
[fixed-seamonkey1.0.3 verified-seamon...
: fixed-seamonkey1.1a, fixed1.8.0.5
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal with 1 vote (vote)
: ---
Assigned To: neil@parkwaycc.co.uk
:
Mentors:
https://bugzilla.mozilla.org/attachme...
: 340732 (view as bug list)
Depends on:
Blocks: 329521
  Show dependency treegraph
 
Reported: 2006-04-05 12:56 PDT by Frank Wein [:mcsmurf]
Modified: 2006-07-26 15:58 PDT (History)
11 users (show)
kairo: blocking‑seamonkey1.0.2-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Proposed patch (903 bytes, patch)
2006-05-19 03:26 PDT, neil@parkwaycc.co.uk
jag-mozilla: review+
jag-mozilla: superreview+
kairo: approval‑seamonkey1.0.3+
kairo: approval‑seamonkey1.1a+
Details | Diff | Review
Alternate patch (718 bytes, patch)
2006-05-19 03:31 PDT, neil@parkwaycc.co.uk
no flags Details | Diff | Review

Description Frank Wein [:mcsmurf] 2006-04-05 12:56:14 PDT
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.
Comment 1 Ruediger Lahl 2006-04-15 16:25:43 PDT
(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
Comment 2 jag (Peter Annema) 2006-04-16 08:53:33 PDT
Frank, could it be an extension that causes this for you?
Comment 3 Frank Wein [:mcsmurf] 2006-04-16 09:04:08 PDT
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).
Comment 4 neil@parkwaycc.co.uk 2006-04-16 15:30:28 PDT
I could just null-check gContextMenu.menu and hope the problem goes away.
Comment 5 jag (Peter Annema) 2006-04-24 09:37:56 PDT
Better steps to reproduce would be appreciated. I'm a bit hesitant to wall-paper over this with a null check.
Comment 6 Serge Gautherie (:sgautherie) 2006-05-18 19:51:14 PDT
[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.
Comment 7 neil@parkwaycc.co.uk 2006-05-19 03:26:51 PDT
Created attachment 222604 [details] [diff] [review]
Proposed patch
Comment 8 neil@parkwaycc.co.uk 2006-05-19 03:31:08 PDT
Created attachment 222605 [details] [diff] [review]
Alternate patch
Comment 9 Serge Gautherie (:sgautherie) 2006-05-19 05:20:37 PDT
(In reply to comment #7)
> Created an attachment (id=222604) [edit]
> Proposed patch

(I would select this one to request review on...)
Comment 10 Serge Gautherie (:sgautherie) 2006-05-19 05:51:48 PDT
(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.)
Comment 11 Steve Chapel 2006-05-20 19:16:27 PDT
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.
Comment 12 jag (Peter Annema) 2006-05-20 19:37:25 PDT
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.
Comment 13 neil@parkwaycc.co.uk 2006-05-21 02:26:56 PDT
(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;
  }
}
Comment 14 jag (Peter Annema) 2006-05-21 04:21:06 PDT
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.
Comment 15 Steve Chapel 2006-06-01 19:26:18 PDT
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.
Comment 16 neil@parkwaycc.co.uk 2006-06-02 02:35:18 PDT
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.
Comment 17 Serge Gautherie (:sgautherie) 2006-06-02 03:13:37 PDT
(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 18 jag (Peter Annema) 2006-06-02 03:59:41 PDT
Comment on attachment 222604 [details] [diff] [review]
Proposed patch

Fair enough, though I think we should also do my suggested change.
Comment 19 Robert Kaiser (not working on stability any more) 2006-06-02 04:09:25 PDT
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)
Comment 20 neil@parkwaycc.co.uk 2006-06-02 04:34:02 PDT
Fix checked in.
Comment 21 Robert Kaiser (not working on stability any more) 2006-06-02 05:22:15 PDT
1.0.2 is gone, and no need to mark as blocking for 1.0.3 as it's checked in already there
Comment 22 Serge Gautherie (:sgautherie) 2006-06-03 17:00:47 PDT
[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.
Comment 23 Ruediger Lahl 2006-06-03 17:35:45 PDT
(In reply to comment #20)

> Fix checked in.

WFM in my Trunk-SM 2006060301

Thanks to all for fixing this bug.
Comment 24 Frank Wein [:mcsmurf] 2006-06-07 16:57:10 PDT
*** Bug 340732 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.