Error: gContextMenu.menu has no properties when switching tabs

RESOLVED FIXED

Status

SeaMonkey
UI Design
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: mcsmurf, Assigned: neil@parkwaycc.co.uk)

Tracking

({fixed-seamonkey1.1a, fixed1.8.0.5})

Trunk
x86
Windows 2000
fixed-seamonkey1.1a, fixed1.8.0.5
Bug Flags:
blocking-seamonkey1.0.2 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed-seamonkey1.0.3 verified-seamonkey1.1a], URL)

Attachments

(2 attachments)

(Reporter)

Description

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

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

11 years ago
Frank, could it be an extension that causes this for you?
(Reporter)

Comment 3

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

Comment 4

11 years ago
I could just null-check gContextMenu.menu and hope the problem goes away.

Comment 5

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

Comment 7

11 years ago
Created attachment 222604 [details] [diff] [review]
Proposed patch
Assignee: jag → neil
Status: NEW → ASSIGNED
(Assignee)

Comment 8

11 years ago
Created attachment 222605 [details] [diff] [review]
Alternate patch
(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.)

Comment 11

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

Comment 12

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

Comment 13

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

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

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

Comment 16

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

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

Updated

11 years ago
Attachment #222604 - Flags: approval-seamonkey1.1a?
Attachment #222604 - Flags: approval-seamonkey1.0.3?

Comment 19

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

Comment 20

11 years ago
Fix checked in.
Blocks: 329521
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed-seamonkey1.1a
Resolution: --- → FIXED
Whiteboard: fixed-seamonkey1.0.3

Comment 21

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

Comment 23

11 years ago
(In reply to comment #20)

> Fix checked in.

WFM in my Trunk-SM 2006060301

Thanks to all for fixing this bug.
(Reporter)

Comment 24

11 years ago
*** Bug 340732 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

11 years ago
Keywords: fixed1.8.0.5
You need to log in before you can comment on or make changes to this bug.