in recent build (i'm using 2001020121 linux .tar.gz Mtrunk), 'open in new window' function in context menu sometimes doesn't work. also, ctrl-left click on the link and middle-button click, used to open link in new window, do not work either. unfortunately, it is hard to reproduce, because it happens now and then, but its definitely a recent regression, i didn't see it with previous Jan 28 build. other functions (Copy link location, etc) in context menu work.

been seeing this for the past days as well - middle-click fails to work in new windows, haved to close and spawn a new to make it work again. Some keys and menuitems die as well btw. Key-navigation.. enterbutton (right now actually). Dunno if that is related, but confirming original bug: open in new window fails intermittently.

err.. seems the enterbutton DOES work - one just doesn't see it. And that bug is new and fixed: 67408. The other observations stand - seen those for days. Currently using 2001020121

In fact, I'm occasionally seeing cases where I can't even get the context menu to show up when I right-click a link. This could be related to various keys/buttons failing, though. Usually, if I run through the top-level menus at this point, the context menu comes back.

reassign.

For me this is a 100% reproducable bug. Since I frequently go to forums and open up 30+ links in new windows I've had "time" to test it out quite nicely =( It seems to happen only when you have first been to another page with frames, for me at least. Step by step reproduction 1) Goto my site at http://members.nbci.com/huszics/ 2) Navigate to Europa Universalis/links and right-click "open in new window" on the EU Forums link. 3) Once there goto general discussion and start right-click "open in new window" a few times (some times only 2 is required, sometimes a lot more). 4) Suddenly appearing beside "open in new window" and "Edit link in composer" you will see 2 more before the first separator, "Open frame in New Window" and "Show only this Frame". From this onwards the contextmenue is just plain dead until you reload the entire page. I just changed from 2001-01-12-xx to 2001-02-01-04 and since this have never happend before it, so shurely is a new "feature".

Sorry, forgot to mention. I'm on a PC running W98SE as OS, so it's not just Linux related.

using comm 2001.02.05.11 on linux, middle+clicking a link works fine for me, as does selecting "Open Link in New Window" from the context menu. very odd. what i did: i started at http://mozilla.org/ and just starting middle-clicking [or selecting from the context menu] the links in the left table [each time in the newest browser window that appeared]. and i did this about 6 or 7 times without failure.

when it intermittently stops working i get this in console: JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties

forgot.. I get that error-msg both when i middle-click a link and when i change focus on that browser-window. Linux 2001020608

Easy way to reproduce this: (tried with 2001-02-07-04 on Win98SE) 1.) Start mozilla 2.) Load www.mozilla.org 3.) Choose "Open Link in New Window" with any link -> 2nd window opens and loads the page 4.) Again, choose "Open Link in New Window" with any link -> 3rd window opens and loads the page 5.) Now, SELECT THE 2ND WINDOW! 6.) Try "Open Link in New Window" - it doesn't work anymore in this window. (Neighter does "Search->Find in this page". See also bug 67575) Setting OS to All.

Nominating, and assigning to me. I'll investigate from the context menu perspective and figure out where things are breaking down.

peter, thx for the testcase --i see the bug now! [using either the context menu or middle+click.] oh, while going thru this, i encountered a weird context menu bug, where the Frame items appear even tho' there aren't any --see bug 68203 for details.

See also bug 68203 which sounds suspiciously like the same bug...

The 3 bugs (this, bug 67575 and bug 68302) looks like different views of the same problem. Step 4. in my testcase can be replaced with (according to 67575) - clicking in the content area - calling Search->Find This is the step when the 2nd window gets into the bad state. Step 5. can be closing the 3rd window it doesn't cure the situation. I verified thet using both step 4 methods have the same results: - "Open Link in New Window" doesn't work - bug 67575: "Search->Find" doesn't work - bug 68302: "Open Frame in New Window" etc. shows up (I found that selecting "Reload Frame" cures the window). Setting keywords: regression, mozilla0.9

*** Bug 68456 has been marked as a duplicate of this bug. ***

I've done some regression testing. This bug is not present in the 2000-01-30 win32 builds. The first build with this bug is 2000-01-31-04.

*** Bug 68504 has been marked as a duplicate of this bug. ***

a "how to repro" is in bug 68504.

law - i think bug 68004 is a dup of this one as well.

I just reported more "open link in new window" fun in bug 68628.

I wrote... > This bug is not present in the 2000-01-30 win32 builds. > The first build with this bug is 2000-01-31-04. Ehem. I meant 2001's builds not 2000's ... Sorry.

I have seen this, too, and found out that after reloading the page, opening a link in a new window works again. Increasing severity since opening links in a new window is my main mode of browsing, and I think lots of others, too.

I tested the testcase mentioned above with regard to clicking on mozilla.org links and I found the following:- Trunk Build immediately prior to branch: cannot open new window. m0.8 branch build 2001021408: CAN now open new window following the same steps. I'm pretty sure that this is now working on the branch because of jag's patch being backed out of the 0.8 branch. (see bug 66034 'Content in mozilla disappears'). Note that this was only backed out of branch so the bug should still be on the trunk. Adding jag to cc.

What about that new pref setting for opening new windows??

h-j: what should this prev be good for? If I want to open a new window, then I want to open a new window. What should the prev control??

*** Bug 69291 has been marked as a duplicate of this bug. ***

There seems to be a pref setting to block opening new windows. It seems that a lot of site's are opening new windows and a lot of surfers like to block that. And because that's a rather new piece of code, with some problems, that might be related. But maybe this bug has nothing to do with that new pref setting, but who knows what?

*** Bug 68248 has been marked as a duplicate of this bug. ***

I see this bug every 3 min. This is a very ugly bug !! I hope this will be fixed ASAP.

This problem got worse over the last week. I used to see it occasionally, but now I see it after opening only 2 or 3 windows.

CC: Christopher Blizzard, since he fixed 67988. I saw this with build 2001022105 / win2k (and older builds). New windows sometimes don´t repaint. If I move the window in the background,the whole page is blank (or only a part). If I scroll or change the window size, the page appears again. If the page contains animated images, I see a blank page but the images are painted correct. If this happend, I get the "/contentAreaUtils.js line 31" error. I´ll attach a screenshot.

Matti what you mention is bug 66034. I have a feeling these two bugs are linked since they started to appear for me at about the same time.

How I reproduced this bug: First, I started Mozilla... dylang@shadowgate:/usr/lib/mozilla$ mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/usr/lib/mozilla LD_LIBRARY_PATH=/usr/lib/mozilla:/usr/local/qt/lib:/usr/local/qt/lib LIBRARY_PATH=/usr/lib/mozilla:/usr/lib/mozilla/components:/usr/local/qt/lib:/usr/local/qt/lib SHLIB_PATH=/usr/lib/mozilla LIBPATH=/usr/lib/mozilla ADDON_PATH=/usr/lib/mozilla MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= Document about:blank loaded successfully Then I loaded a URL, and proceded to middle-click open a bunch of windows... Document http://www.mozilla.org/ loaded successfully Error loading URL about:blank: 804b0002 Document http://www.mozilla.org/performance/ loaded successfully Error loading URL about:blank: 804b0002 Document http://www.mozilla.org/mailnews/win_performance_results.html loaded successfully Error loading URL about:blank: 804b0002 Document http://www.mozilla.org/mailnews/linux_performance_results.html loaded successfully Error loading URL about:blank: 804b0002 Document http://www.mozilla.org/mailnews/mac_performance_results.html loaded successfully Then I decided to close off the performance_results URLs so I could try middle clicking into a different pages.... JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties Wow, lots of these! One for each page first off, then one for each middle click I tried to use... JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties JavaScript error: chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no properties Having found the probably cause, I hit ctrl+n, and pasted in the URL for this bug to make this report. Error loading URL about:blank: 804b0002 Document about:blank loaded successfully Document http://bugzilla.mozilla.org/show_bug.cgi?id=67442 loaded successfully

*** Bug 70309 has been marked as a duplicate of this bug. ***

*** Bug 70788 has been marked as a duplicate of this bug. ***

Could a Javascript/XUL bug of some sort be causing this and bug 67574?

If this bug appeared between 2001-01-30 and 2001-01-31, that coincides with the range (2001-01-23 to 2001-02-03) where bug 67574 seems to have appeared -- maybe this is coincidental, or maybe it's significant. Were there any Javascript/XUL changes on the night of 2001-01-30?

Okay got 100% Reproducible testcase here so get it while its hot people: 1) Open a browser Window and goto a webpage 2) Open a Mail/News Window 3) Double-Click Several times very fast on the 'Online/Offline' icon 4) Switch to your Browser Window...Everything is keydead..try clicking on links or buttons and the Open link in New Window is dead too. Try it out it may take you a couple of tries but you will see it.

Oh yeah and in the Javascript Console this is displayed: Error: srGetStrBundle is not defined Source File: chrome://communicator/content/utilityOverlay.js Line: 40 Column: 0

Could it be that the fix for bug 25455/ 67079 may be involved in this? It was related to window-creation and is the only "obvious" candidate i find checked in during the timespan this regression seems to have surfaced. The thing that makes this bug trigger most often is if i "open link in new window" and then change focus between windows during window-creation/load.

The test case stated by P?ter Bajusz on 2001-02-08 01:59 is completely reproducible if followed properly and I feel is more properly related to this bug than that pointed out by Keyser Sosez on 2001-03-06 19:08. Rkaa, as I pointed out in an earlier comment it is also highly likely that this was caused by disttsc%bart.nl on 1/30/2001 (see Kevin McCluskey 2001-02-08 19:01 comments in bug 66034). Note that when this was backed out of the M0.8 branch both this bug and bug 66034 were fixed on the branch.

I'm pretty sure this has the same origin as bug 66034. What I think the problem is, is that due to javascript garbage collection we're hanging on to an object (the content viewer) which relies on being destroyed from its destructor instead of explicitely being destroyed. This keeps it hanging on to a few objects longer than expected, which I suspect is also causing these link clicks to go to the wrong object. A fix, other than "just back everything out" is hard to come by, though if I can't get this fixed soon I'll try to get the same work-around that was applied to the 0.8 branch checked in.

I agree, and so I'm reassigning this to you :-). I've got another similar looking problem relating to Find on view-source, which I'll be sending your way also.

Jag, could you set the priority and milestone for this bug? Since it's generating so many dups, it might make sense to back the change out and search for the real fix in your local build.

Okay, let me whip something up.

Jag's patch worksforme on win2k.

You use both direct and copy init in the part you reverted. I know it's not your code, but please change it for consistency. Also, I was surprised to see filenames with the extension `.fuck' at the beginning of the patch. My virgin eyes and ears don't know what this word means, but they've seen and heard it in negative contexts before. r=blake if you fix the init and promise never to show me that evil, evil word again.

It's code that's going to go away RSN (again!). Watch me not care about direct vs copy init.

I checked in the work-around a while back, this should work now. Keeping the bug open, moving to 0.9, reducing to normal.

This still sucks big-time for urls loaded from an external app (irc, shortcut) from mail/news messages, and from open link in new window.

worksforme with Linux build now.

I suspect the fix of bug 76024 to also fix this.

worksforme in Windows and Linux now -- seems resolved

win32 talkback build 2001051604, win98se Had just started it, 1 browser window open. 'open link in new window' didn't work on any link. It started working after I shut mozilla down and started it again. BTW, I think this was the first time I ever saw this problem.

Mass move to jaggernaut@netscape.com

resolving as dup of 66034, per jag, who says they share the same root cause. *** This bug has been marked as a duplicate of 66034 ***

VERIFIED dup