Closed Bug 67442 Opened 24 years ago Closed 23 years ago

'open link in new window' doesn't work all the time

Categories

(SeaMonkey :: UI Design, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 66034

People

(Reporter: kmike, Assigned: jag+mozilla)

References

Details

(Keywords: regression)

Attachments

(2 files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Assignee: asa → vishy
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
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.
OS: Linux → All
Nominating, and assigning to me.  I'll investigate from the context menu
perspective and figure out where things are breaking down.
Assignee: vishy → law
Keywords: nsbeta1
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.
Severity: normal → major
Hardware: PC → All
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.
Severity: major → critical
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.
Assignee: law → disttsc
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.
Priority: -- → P1
Target Milestone: --- → mozilla0.8.1
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.
Severity: critical → normal
Target Milestone: mozilla0.8.1 → mozilla0.9
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.
Depends on: 76024
Target Milestone: mozilla0.9 → ---
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
Assignee: jag → jaggernaut
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
VERIFIED dup
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: