Closed
Bug 332874
Opened 19 years ago
Closed 19 years ago
Error: gContextMenu.menu has no properties when switching tabs
Categories
(SeaMonkey :: UI Design, defect)
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)
(deleted),
patch
|
jag+mozilla
:
review+
jag+mozilla
:
superreview+
kairo
:
approval-seamonkey1.0.3+
kairo
:
approval-seamonkey1.1a+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•19 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•19 years ago
|
||
Frank, could it be an extension that causes this for you?
Reporter | ||
Comment 3•19 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•19 years ago
|
||
I could just null-check gContextMenu.menu and hope the problem goes away.
Comment 5•19 years ago
|
||
Better steps to reproduce would be appreciated. I'm a bit hesitant to wall-paper over this with a null check.
Comment 6•19 years ago
|
||
[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•19 years ago
|
||
Assignee: jag → neil
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•19 years ago
|
||
Comment 9•19 years ago
|
||
(In reply to comment #7)
> Created an attachment (id=222604) [edit]
> Proposed patch
(I would select this one to request review on...)
Comment 10•19 years ago
|
||
(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•19 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•19 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•19 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•19 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•19 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•19 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)
Comment 17•19 years ago
|
||
(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•19 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•19 years ago
|
Attachment #222604 -
Flags: approval-seamonkey1.1a?
Attachment #222604 -
Flags: approval-seamonkey1.0.3?
Comment 19•19 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•19 years ago
|
||
Fix checked in.
Blocks: 329521
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed-seamonkey1.1a
Resolution: --- → FIXED
Whiteboard: fixed-seamonkey1.0.3
Comment 21•19 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-
Comment 22•19 years ago
|
||
[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•19 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•19 years ago
|
||
*** Bug 340732 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•18 years ago
|
Keywords: fixed1.8.0.5
You need to log in
before you can comment on or make changes to this bug.
Description
•