Closed Bug 78725 Opened 23 years ago Closed 23 years ago

Right-click doesn't reliably bring up context menu (first time only?)

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: kbh7, Assigned: hyatt)

References

Details

(Keywords: regression, Whiteboard: NEED SR, critical for 0.9.1)

Attachments

(1 file)

Back out popup set. Fix crash in outliner.
2.19 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; rv:0.9+) Gecko/20010503
BuildID:    2001050306

Right-clicking on an empty area of the document doesn't always
bring up the context menu.

I'm not sure what makes it work sometimes.  It appears to work
for links/images, and then once on an empty part of the document,
but not again.

Reproducible: Sometimes
Steps to Reproduce:
1. Open any page (like about:blank)
2. Right-click to bring up the context menu.
3. Right-click again somewhere else.

Actual Results:  No menu!

Expected Results:  Expected to see the context menu again.

My last nightly was 20010430??, and it worked fine there, so it
was something recent.
Confirming in 050304 trunk for Mac.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Confirming on Windows ME Build 050304
Confirming in Win98 050304. As a side effect, this also causes the first
subsequent click or drag to be lost.
Severity: normal → critical
Bug 78373 describes a similar problem.
Did some digging on this with Spy++ on Windows.  When a context menu appears,
there is a WM_CONTEXTMENU message, followed by a few WM_SIZE messages to make
the context menu the correct size.  When the menu is taken down, there is a
WM_SIZE message to set it to size 0,0.

When the context menu doesn't appear, the WM_CONTEXTMENU message is sent, but
there is no subsequent WM_SIZE.  This means a context menu has size 0,0, but
it's really there.  This also explains the loss of the subsequent click, because
that click is functioning normally;  it's making the invisible context menu go away.
Another way to reproduce.
Load some bugzilla url with links to another bugs (they have the yellow tooltips).
Position the cursor over the link to make the tooltip to show. Then press right
click -> menu should appear, but it doesn't. And it actually doesn't appear till
you right click on the empty place on the page.

here is what I found:

right click in open space. click off the menu.  From now on all right clicks
into areas that use the same context menu results in no context menu being
shown.  The menus are being initiated but they never become visible(my mouse
wheel doesn't work when the context menu is up. all odd number of right clicks
on the same area results in unworking scroll.  even numbers dismiss the context
menu and allow the scrolling to work).  Since the context menu is being intiated
the very next mouse click just dismisses this invisible context menu, that
explains some of the spottyness when clicking between different types of context
menus and all other unresponsiveness of mouse buttons for 1 click.

Right clicking where another context menu is used, such as on a link, results in
the context menu being show again.


with regards to  Tom Mraz's statements:  at first I thought I was seeing what
you mentioned but after closer examination I find that the context menu shows on
the first right click of the links.  All right clicks after that onto any other
place that uses the same context menu will result in the context meny not being
visible.  right clicking on the text and then clicking off the context menu and
then right clinking onto the link does bring the context menu up.

I think some assumptions are being made that aren't true after the menu has been
displayed once...

hope this helps and makes sense,
Chris


*** Bug 78879 has been marked as a duplicate of this bug. ***
keywords
Keywords: mozilla0.9.1, regression
Summary: Right-click doesn't reliably bring up menu (first time only?) → Right-click doesn't reliably bring up context menu (first time only?)
*** Bug 78893 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1, nsCatFood
From dup bug 78888 Comments From Conor Lennon 2001-05-04 06:57  "..seems to have
occured between Build 2001050108 and Build 2001050221."

I tested on build ID 2001050204 and context menus are functioning ok, so
concluding that this was broken between 2001050204 and 2001050221. 


bug that might be related - surfaced at the same time - was bug 78895
ok, here is what i see:

get a context menu on a link. dismiss it. Try again, nothing. Move it to a place
without a link, and it works. Dismiss it, and again, nothing.

Also, composer is not affected, mailnews is as is navigator.
This was working reliably in 05/02 morning mozilla verif. builds (right click 
gets menu, click in content dismisses, another right click gets menu). 

But in the evening builds for 05/02, this does not work (right click gets menu,
click in content dismisses, another right click ... no menu comes up). 

Given that pinkerton's away, I doubt that this is a change he made :-]. It
seems like higher level code to me anyways. Looking over the checkins in that 
window, I'd say this is most likely related to alecf's changes for the browser 
content listener. Alec?
p2/0.9.1
Blocks: 75643
Priority: -- → P2
Whiteboard: need for 0.9.1
Target Milestone: --- → mozilla0.9.1
*** Bug 79026 has been marked as a duplicate of this bug. ***
*** Bug 79045 has been marked as a duplicate of this bug. ***
*** Bug 79055 has been marked as a duplicate of this bug. ***
*** Bug 79075 has been marked as a duplicate of this bug. ***
Eight dups in 3 days, eleven votes and a related bug. Adding mostfreq.
Keywords: mostfreq
Now it just needs to be assigned. I want this fixed in Monday's build...
This is Hyatt's check-in to nsPopupSetFrame.cpp.

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&su
bdir=mozilla/layout/xul/base/src&command=DIFF_FRAMESET&file=nsPopupSetFrame.cpp&
rev1=1.68&rev2=1.69&root=/cvsroot
Hyatt, was this a typo?  If I change "if (childContent.get() != aPopupContent)" 
to use "==", it works again.
*** Bug 79149 has been marked as a duplicate of this bug. ***
*** Bug 79159 has been marked as a duplicate of this bug. ***
Blocks: 78895
That is not a typo.  The purpose of that loop is to ensure that only one popup 
is generated at a time.  Since you're going to promptly generate a particular 
popup, you shouldn't waste the time ungenerating that particular popup.  So the 
loop is just ensuring that all OTHER popups are ungenerated.

In fact if you change that line, you'll crash typing into the URL bar, since 
the autocomplete widget will thrash while destroying and recreating its 
outliner popup.

How do we resolve this regression while still maintaining what you added?
Just for the record, document.popupNode in build 2001041704 returns a different
element as build 2001050608. This can't be correct is it!
H-J, probably not.  Could you file a bug on dr@netscape.com about the popupNOde 
issue?

--> me, since pink is out.
Assignee: pinkerton → hyatt
my guess is that we don't correctly notice that the first context menu went 
away...
*** Bug 79234 has been marked as a duplicate of this bug. ***
*** Bug 79293 has been marked as a duplicate of this bug. ***
David, I filed bug 79416 for the document.popupNode thing!
First of all there are several contextmenu's in mozilla. We have context menu's
for images, links and page content, just to name some, and none of them work as
they did before.

Tip:
When a contextmenu doesn't show up anymore (but you need it), try to activate
any other contextmenu for that page, for images or links for example. Then
reactivate the contentmenu you need, this will allow you to open the contextmenu.
*** Bug 79604 has been marked as a duplicate of this bug. ***
*** Bug 79693 has been marked as a duplicate of this bug. ***
H-J, I think I found an exception to your Tip.

Go to: http://www.phpbuilder.com/

Try getting a context menu anywhere on that page.  I was unable to on win2k 
with build 2001050904 

Maybe a common denominator can be found now that one particular site seems to 
be obstructing any context menu whatsoever?

jake
*** Bug 79716 has been marked as a duplicate of this bug. ***
I'm not sure about the http://www.phpbuilder.com/ issue, as I was just able to
get popups to work just as in other places with build 2001050304.
Jake, this issue is something more recent, as original reporter wrote in his
comment. 

BTW: take a look at your JS console for these warning:

Error: doc has no properties
Source File: chrome://communicator/content/nsContextMenu.js
Line: 646

Error: contextMenu has no properties

Error: contextMenu has no properties
Source File: chrome://cookie/content/cookieContextOverlay.xul
Line: 94

*** Bug 79763 has been marked as a duplicate of this bug. ***
*** Bug 79826 has been marked as a duplicate of this bug. ***
*** Bug 79830 has been marked as a duplicate of this bug. ***
Whiteboard: need for 0.9.1 → critical for 0.9.1
Clearly high visibility and highly annoying - workaround is not obvious. Suggest
Priority P1 instead of P2?

*** Bug 79879 has been marked as a duplicate of this bug. ***
*** Bug 79906 has been marked as a duplicate of this bug. ***
Reporter in bug 79906 says bringing up another context menu doesn't make 
URL-bar's context menu re-appear: It can only be triggered once per session.
Leaving it dup'ed  but when verifying fix, perhaps check context menu in NT
URL-bar in particular.
6 hours old CVS build on RH7.1: Hard to repro but perhaps it means something:

right-clicked a link - left-clicked in empty area - right-clicked link again:

error message in console:
 JavaScript error: 
chrome://communicator/content/nsContextMenu.js line 374: can't convert
elem.background to an integer

Was reproduceable all the time till i loaded another page - then went away.
the error in nsContextMenu.js is reported in bug 79666

but I dont see any error when trying to get the context menu. So I think the 
error in nsContextMenu.js is another problem.
URL: http://any
*** Bug 79970 has been marked as a duplicate of this bug. ***
Wow. 19 duplicates... is there any progress on fixing this bug?
>but I dont see any error when trying to get the context menu. So I think the 
>error in nsContextMenu.js is another problem.

Henrik, please visit mozillaZine.org or phpbuilder.com and right-click on the
top image, then you should see this JS error, as Fabian and me, and others did see.

Error: doc has no properties
Source File: chrome://communicator/content/nsContextMenu.js
Line: 646

I can't reproduce the JS error in line 374 reporter by R.K.Aa, it is a
background image issue!

One thing I think I've foudn might help.  It seems that if you right click on a
link to open it in a new window, you can no longer right click links, but you
*can* right click white space (once.  then that quits working).  But if you go
back to a link, you can now right click that and get a context menu.  After
having done that, you can get a CM for the white space, and so the circle
continues.  Hope that helps (and I'm not smoking crack... :)
hehe "not smoking crack" ;)
but you're right :)
*** Bug 80036 has been marked as a duplicate of this bug. ***
The problem here is almost certainly the context menu being brought up sized as
0x0. Try right clicking, pressing down and then enter. This should activate the
first option on the context menu, normally either back or open link in new window.

I also found the following error in my js console, not sure if it is related. 
Error: [Exception... "Component returned failure code: 0x80040111
(NS_ERROR_NOT_AVAILABLE) [nsIURIContentListener.canHandleContent]"  nsresult:
"0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame ::
chrome://navigator/content/nsBrowserContentListener.js :: anonymous :: line 134"
 data: no]
Source File: chrome://navigator/content/nsBrowserContentListener.js
Line: 134

I have also managed to get several instances of the nsContextMenu.js can't
convert elem.background message. I have had this error when right clicking on
links, but not all links. I got it consistantly on
http://bugzilla.mozilla.org/showvotes.cgi (the links to bugs).

I'm using 2001050915.
I just tried that suggestion (right-click, down, enter) and it did produce the
page in a new window. So it seems you're right in suggesting the menu is brought
up sized 0x0...

Menu is size 0.  That's basically what I wrote in my comment on May 3.  The 
problem here is, why is the menu that size?
that exception is unrelated to the context menu.
Slightly off-topic: after a right-click to bring up a context menu, the next
left click gets swallowed. Is this supposed to be so?
o.v.k: see bug 72859
this has regressed even further for me in today's win32 build 051104 on win2K. 
The workaround no longer works and all right-click functionality is gone.  It
doesn't even work the first time.
Yeah, I noticed this yesterday.  Also, it's sometimes tough to get menus to open
up from the menu bar.  Request raising this to P1.
I am also seeing menus on the menubar fail to pop uot on the first click. Many
times it takes a second click to open a menu. Tested with 051104 win32 build on
win2K
i would raise to secerity "blocker" now and priorty "p1"
this bug starts to be really annoying
wow, 64 votes
Blocks: 78290
My Linux build from today has still got right-click menus, as per day one of
this bug.

context menus are failing for me on Linux mozilla build 051108 (workaround does
not work and I don't even get them the first time on a page).
Sigh

I can confirm on Windows 98 SE, Build 2001051104, that context menus do not work
at all.
Facing same problem on WinNt 4.0 2001051104 (Workaround no longer works). Also 
facing the "2-clicks required" problem on all menu items as someone mentioned 
above.
Confirming no context menus for WindowsME on today installer build 2001051104.

Do we need Win2K as well? ;-)
Confirming no context menus at all now on Win2k SP1, build 2001051104.]
I *know* I had them earlier.. they aren't where I left them..


So we have a new blocker? And godfood and catfood etc... :(((

how is this a blocker? There are workarounds for each context menuitem right?
not for many things - Save Link As, Save Image As, etc..
Do you mean for example copy & paste in the URL fields instead of Open in New 
Navigator Window? Actually as Paste is not very reliable in Mozilla the 
workarond in many instances is to copy the text manually. Or is the workaround 
just opening the page in the same window? 

I think it should be a blocker.

BTW, is "godfood" a bug so difficult that mere mortals cannot fix it?
removing myself from Cc:
Can someone try backing out 79720 and see if it fixes the top-level menu 
problems?  That would be my suspect for the recent regression, since people are 
only seeing it on Win32.
Status: NEW → ASSIGNED
alecf, doesn't shift+click work to save link as and save image as? Jacek, for
opening link in a new window try Ctrl+click on a link.  The painful one is Copy
Link Location. 
there's also view image, save image as, etc...
Severity: critical → blocker
This is a combo blocker because link dragging is broken.  I can't drag links,
and I can't copy a link, so I can't browse in two browsers.
adding smoketest to get blocker status re: baker's comments
Keywords: smoketest
how will we be able to move non-critical target milestone 0.9.1 off to other
milestones if this doesn't get fixed?  there is some kind of plot going on here.. 
*** Bug 80118 has been marked as a duplicate of this bug. ***
dragging links has been broken for days, isn't there another bug for that?

what on earth does link dragging have to do with context menus!??! removing 
smoketest keyword
Keywords: smoketest
This is getting even worse! Now I can't get any context menus at all using build
20010511 Win98. Is any work being done to fix this soon? Without access to the
context menu, it makes it difficult to test other aspects of the browser.
Yes there is.  I just mention it to show that the combination of the two bugs is
a real killer.  BTW I didn't add the smoketest keyword, because as far as I can
see you can complete all the smoketests without the context menu.
I know this really isn't meant to be a general forum for discussing development
issues, but as an active user of the product, I'd have to say that seeing this
bug is rather frustrating.

I tend to agree with Skewer on this one, in that I don't understand why an
obviously MAJOR bug like this could stay in the system for so many days.  This
bug was initially opened on the 3rd of May, and now 8 DAYS later it still has
not been fixed, and there is no mention of a fix in the comments for the bug.

There are over 70 votes, and it appears that there are at least that many people
on the CC list, so obviously a LOT of people consider this bug critical.  Why
then is no fix apparant?

Sorry for the rant, it just seems like something has to be wrong here.

If you want to bring that up, take it to a newsgroup no news.mozilla.org.  The
discussion here is for working toward a resolution of the problem.
context menus and menus are back after hyatt backed out rod's change from 
yesterday. 

hyatt's backout was for bug 79720.
*** Bug 78895 has been marked as a duplicate of this bug. ***
Whiteboard: critical for 0.9.1 → NEED SR, critical for 0.9.1
*** Bug 80357 has been marked as a duplicate of this bug. ***
wow, 20 emails... removing myselt from CCs list

;-)
*** Bug 80410 has been marked as a duplicate of this bug. ***
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Build 2001051120 on Win2k SP1, back to same status as at the start of this bug,
ie. first click opens properly, second opens with size 0x0. Also, can only open
a context menu for the urlbar once per session, even using the workaround, all
future attempts cause it to open at 0x0 (can scroll it using keys to get to
select all).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
workaround works (right click on a link, rightclick on background and so on)
but not twice on the same kind of field (2 times on a link for example)

regression
James Eavis: 
------- Additional Comments From David Hyatt 2001-05-12 01:46 -------

fixed.

look at the post date, it´s 2001-05-12 and you are using build 2001051120.
This bug is fixed in build 20010512..
This this is fixed for me with a CVS build.

marking fixed again !

SORRY for the SPAM
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Linux Build 2001051206

Context menu seems to work ok. But on this page ( http://www.xmms.org / ) they
dont work at all. Very extrange.

Sorry for the Spam
Context menu behavior has greatly improved, but has not been fixed. Context
menus will still stop working after I cancel out of an open menu with a left
click outside of it.

Suggest reopening bug with narrowed description like "Context menus less
reliable after being canceled" and severity of "minor."
Sorry, I should add some steps to reproduce this so you don't dismiss my remark
as unreproducable.

Procedure: Right-click any element (text box, canvas, link). Click outside of
the context menu to close it. Right-click that same element again (not a
different element).

Expected: Context menu is opened again.

Actual: Context menu is not opened, and will not open until you right-click a
different type of element.
thats exactly what this posting is about... exactly that, meanwhile we disabled 
right clicking completely and now it works like it worked at the beginning 
again...
Linux build 2001051206

Context menu also doesn't work at http://www.hotmail.com, which I believe is a
top100 site. The problem can be reproduced as in Skewer's comment.
Linux 2001051206:

I can't reproduce Skewer's bug. (What platform/OS/build was it?)

I also have no context menus on www.xmms.org. If I remove the
background="..." from the <body> tag on www.xmms.org, it works.
Hmmm, actually, context menus don't seem to work on any pages
that use background="some_image". Does this help anybody?

On pages with background images, I get no context menu and the following
Javascript errors:

Error: doc has no properties
Source File: chrome://communicator/content/nsContextMenu.js
Line: 646

Error: contextMenu has no properties
Source File: chrome://cookie/content/cookieContextOverlay.xul
Line: 94

Mozilla 2001051206 on Linux
Context menu won't work with pages that have a background.  
See bug 80473.
I also cannot reproduce skewers bug.  Win2ksp1 build 2001051208.  This bug seems
fixed to me.
This bug is WorksForMe on build 2001051208, with an exeption for background images.
On Windows Me - context menus are back for me on build 20010512, but I can't get
any kind of context menu up on Hotmail as per Skewer's comment.
Works for me now, 20010512 Win98.
Checked hotmail.com login page, behavior described above still occurs in this build.
hotmail.com also suffers from one of the many "never stops loading" bugs which
are floating around, though that shouldn't make a difference here; I can also
not get a context menu on that site.

for those of you still complaining about xmms or hotmail: as has been mentioned
already in this bug, bug 80473 is the one that's causing your problem as both of
those pages have background images.
Re: context menus on pages with background - I can confirm that's fixed in my
brand new linux build from the tip. There are no remaining issues on context
menus that I know of here.

*** Bug 80514 has been marked as a duplicate of this bug. ***
*** Bug 80593 has been marked as a duplicate of this bug. ***
new thing: now in build 2001051222 i can't type anything after i've right 
clicked some times!! under win2k sp1 - seems the whole keyboard gets disabled 
in mozilla, because i can't even press ALT+F for the file menu or anything
Harald, you're probably seeing bug 30841.
yeah, seems so, but mhh it started to happen for me since this bug here is 
fixed!
This bug is fixed, verifying it as so.  Any problems should be logged as new 
bugs.  But please search Bugzilla carefully as most of these have already been 
logged.
Status: RESOLVED → VERIFIED
*** Bug 81348 has been marked as a duplicate of this bug. ***
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: