Follow these STR in order to get a huge context menu (see screenshot). 1) Hold down right-click on a page 2) Move your mouse to the status bar 3) Let go and a huge context menu comes up Only does it once per session, restart Firefox and you can reproduce again. No errors in the error console.

Confirmed except a) I can reproduce it until I open a context menu somewhere else b) I see the following two messages in the Error Console Error: this.target.ownerDocument is null Source File: chrome://browser/content/nsContextMenu.js Line: 518 Error: tipElement.ownerDocument is null Source File: chrome://browser/content/browser.js Line: 2200 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008032705 Minefield/3.0pre ID:2008032705

IMO this should be a blocker as it is not only annoying but bound to get picked up by reviewers, so I have set a request for blocking FF3. This should get the drivers looking at it and get a quick fix in. Confirmed on Vista 64.

This is an edge case and in no way constitutes blocking a major release for something that isn't going to be found by a even a small minority of users. I feel bad for the drivers having to review almost every bug that is filed after a flag is added because everyone things every bug is important enough to block a release. I personnel wish only bugzilla users with canedit privileges could request blocking status.

is this a regression?

Not sure if it's a regression, but it's not a blocker. Gavin says that this is happening because we're not properly handling an exception. I'll also note that left-clicking in the content area before performing the STR prevents this from happening for some reason.

(In reply to comment #4) > is this a regression? (Bug 431664 comment #3) > Regression range: > http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-11-30+22%3A00&maxdate=2006-12-01+06%3A00 > It is not clear what bug might have caused this, there are several > possibilities. This is reproducible by right-clicking and dragging to anywhere out of the content area. (status bar, bookmarks bar, tab bar, out of window, etc.) Error shown in error console in each instance is currently: Error: this.target.ownerDocument is null Source File: chrome://browser/content/nsContextMenu.js Line: 531 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090225 Shiretoko/3.1b3pre Can't reproduce in Linux, as there it opens context menu on mousedown instead of mouseup.

When this should be a regression we need a regression range to identify the causing patch. Is anyone interested to check this? It would be very helpful.

(In reply to comment #12) > When this should be a regression we need a regression range to identify the > causing patch. Is anyone interested to check this? It would be very helpful. I wouldn't think we have hourlies that go back to 2006, so I think Ria Klaassen's nightlies regression range from bug 431664 comment 3 which I quoted in comment 8 here is probably the best we can hope for.

To give a reference. The error happens here: http://mxr.mozilla.org/mozilla-central/source/browser/base/content/nsContextMenu.js#590 0001: this.target $[0] = [XPCNativeWrapper] [class: XPCNativeWrapper] {16} 0001: this.target.ownerDocument $[1] = [null] null 0001: this.target.nodeType $[5] = [integer] 9 0001: this.target.defaultView $[6] = [XPCCrossOriginWrapper] [class: XPCCrossOriginWrapper] {0} So this.target is already the document (nodeType == 9). That's why accessing this.target.ownerDocument returns null.

Thanks Dave! According to my tests in comment 14 and the given regression range I blame the patch from Mano on bug 185239: "print frame" in context menu (under "this frame").

Still happens in Firefox 3.6, but it seems to be random (and is annoying)

Comment on attachment 422939 [details] Screenshot2 FF3.6 (Win7x64) Reproducible. Start firefox, rightclick and drag outside content.

(In reply to comment #14) > So this.target is already the document (nodeType == 9). That's why accessing > this.target.ownerDocument returns null. If I am following bug Archaeology correctly then bug 360731 might be when it began as it seems to have started firing event at the document: > + } else if (mDocument) { > + nsEventDispatcher::Dispatch(mDocument, mPresContext, aEvent, > + nsnull, aStatus, nsnull);

What about a fix or a block?

You can confirm this if you right click on video 4-5 times you will have it ,much worse then 3.6.4(3)

Black_Ps' and Tony: Thanks but this bug is well known so there is no need to further comment or add anymore screenshots.

So, I read my patch for bug 185239, and I'm not sure how it could affect this. The target.ownerDocument usage is within the printFrame method. meaning you need to actually click "print frame" to get through that code path.

(In reply to comment #23) > (In reply to comment #14) > > So this.target is already the document (nodeType == 9). That's why accessing > > this.target.ownerDocument returns null. > > If I am following bug Archaeology correctly then bug 360731 might be when it > began as it seems to have started firing event at the document: > > > + } else if (mDocument) { > > + nsEventDispatcher::Dispatch(mDocument, mPresContext, aEvent, > > + nsnull, aStatus, nsnull); Olli, could you please look into this?

I don't know what to look at. The .js code seems to have bad assumption that event.target.ownerDocument is non-null.

(In reply to comment #36) > I don't know what to look at. > The .js code seems to have bad assumption that event.target.ownerDocument is > non-null. Why does the context menu open with the document as the target in the first place when releasing the mouse button elsewhere?

I would still like to know whether we should really expect this state in the first place...

Comment on attachment 459856 [details] [diff] [review] fix / workaround (checked in) Shouldn't we handle this as if the <html>/<body> element was the target?

(In reply to comment #41) > Comment on attachment 459856 [details] [diff] [review] > fix / workaround > > Shouldn't we handle this as if the <html>/<body> element was the target? I don't think so. The user released the mouse outside of the content area when this happens, thus my question in comment 37.

Comment on attachment 459856 [details] [diff] [review] fix / workaround (checked in) Oh, then we should do this either way. r=mano.

Comment on attachment 459856 [details] [diff] [review] fix / workaround (checked in) http://hg.mozilla.org/mozilla-central/rev/36a1aa3cde94 Leaving this open, pending a response to comment 37.

(In reply to comment #44) > Comment on attachment 459856 [details] [diff] [review] > fix / workaround (checked in) > > http://hg.mozilla.org/mozilla-central/rev/36a1aa3cde94 > > Leaving this open, pending a response to comment 37. Olli, I believe that is you?

Comment on attachment 459856 [details] [diff] [review] fix / workaround (checked in) Fix is checked in, removing approval because its still opening on showing up for FF4 release.

I could reproduce this bug. Here's a video: http://youtu.be/lvx0WgtMmy0

I have almost exactly same. Except my context menu is blank, I have to scroll up to get any (looking for open in new tab or window I use all the time). When I get it to show, it doesn't work. In other words HUGE context menu, blank, with arrow at top/bottom, can find open in new tab, but when clicked, doesn't do anything. My screen shot looks exactly like one above posted with bug - except my huge menu is empty. SeakMonkey 2.2, new user just found (love).

I'd say this should be marked as fixed.

Again encountered this bug in the last two nightly builds. Short video - http://www.datafilehost.com/download-6c801f2b.html The context menu is in the order if the extension Omnibar is disabled. :::: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 Win7 x64, latest Nightly build x86.

I just saw a Huge Context Menu with all commands appear in Firefox's built-in PDF reader (Aurora 2012-11-08), after right clicking on the content area. It also acted as a nice reminder to disable that feature and let my current plug-in handle PDF files instead.

In the past week i've encountered this bug on 3 different machines running Firefox; 2 of which are Windows 7 and one of which is Fedora 18. Restarting firefox resolves the issue, I haven't noticed a pattern to when this bug is triggered.

Comment on attachment 748749 [details] Bug in Firefox 20 Yup, same here, on Ubuntu 12.04.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 This issue has been tested on an older version of Firefox (3.6, Build ID: 20121011030552) on Win 7 x64 , and it was reproducible. When holding down right-click on a page and moving the mouse to the status bar or outside the browser window and releasing it there, a long context menu appears. However this issue has been tested on Win 10 x64, Win 7 x64, Win Vista x32, Win XP x32, with the latest Firefox release (46.0.1, Build ID: 20160502172042) and with the latest Nightly(49.0a1, Build ID: 20160530071207) and it is no longer reproducible. Considering this I will mark this issue as Resolved-WORKSFORME. If anyone still encounters this issue feel free to reopen it or file a new one.