Closed Bug 82159 Opened 24 years ago Closed 24 years ago

Linux and Mac don't display window opened via window.open() or target anchor attribute

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ckritzer, Assigned: adamlock)

References

(
URL
)

Details

(Keywords: platform-parity, regression, Whiteboard: 0.9.1?)

Mitch, I assigned this to Security General because it seems like it might be yours, but if not, I know you'll find the right owner :-) Overview: Linux build of 2001-05-22-05-trunk will not display the window opened via the window.open() js. Two examples are the one above plus: http://voodoolady.mcom.com/security/accept/aubr005.html The test in the URL field of this bug shows how the window does not appear. The testcase shows how the window does not appear, but the testcase will be reading info from the window regardless. Platforms tested on: -MacOS91 2001-05-21-15-trunk -Win98SE 2001-05-22-06-trunk -LinRH62 2001-05-22-05-trunk Questions/comments/etc welcome.
Blocks: 57414
All/All. The url http://voodoolady.mcom.com/security/accept/aubr005.html contains no content at all (<html><body></body></html>).
OS: Linux → All
Hardware: HP → All
*** Bug 82095 has been marked as a duplicate of this bug. ***
Serious regression, probably a 0.9.1 stop-ship? Updating summary.
Keywords: mozilla0.9.1, regression
Summary: Linux doesn't display window opened via window.open() → opening new windows via target or window.open doesn't work
Whiteboard: 0.9.1?
The testcase is an internal link only. Changing back to HP/Linux.
OS: All → Linux
Hardware: All → HP
Changing summary
Summary: opening new windows via target or window.open doesn't work → Linux doesn't display window opened via window.open()
ckritzer: you've given Win98 as a platform you've tested on. That means All/All. Plus I see the javascript:void(window.open("about:")); problem on PC/Linux and dark@c2i.net sees it on a target="external" link. Why are you reverting to old Platform/OS and summary? Am I missing something here?
Blocks: 56053
jg, As of the bits I'm running from 2001-05-22-xx-trunk on all builds, this problem only happens on Linux. Yep, I ran the testcase on Win98 as well as LinuxRH6.2 & MacOS9.1. Absolutely. I always test every bug or potential bug on Win98SE, LinuxRH6.2, and MacOS9.1, as those are the systems on my desk. But this bug only appears on the Linux build from this morning. If you are seeing it happen on Windows or MacOS from the same builds I'm running, then feel free to comment as such. However, if you don't have two or more platforms (running latest bits) to confirm this behaviour on, I would appreciate if you wouldn't change the bug summary & platform/os, as it makes the engineer's job (and mine) more difficult in tracking these problems down. Thanks, -Kritzer
Observation on this bug: apparently the windows are being created but just aren't being displayed. To observe this, make several attempts to open a URL via window.open and then look at your "Tasks" menu. You'll probably notice that there're entries for every one of the times you tried to open a URL... they won't appear if you click on the entries though. Also look at mozilla's memory useage with top and you'll see that the windows are there too :-\
Blocks: 78783
Hmm, noticed the creation-and-not-displayed-ness of the windows, but didn't catch the leaks. Good job, Dave.
Ah, so you tested on Win32 and it wasn't a problem. Sorry, I misunderstood you. But this is certainly not an HP platform-specific issue, I see it on PC. Marking Platform/All, but I note that we don't have a test result for LinuxPPC. Keyword pp also applies here. Also adding to summary. Does this really belong in Security?
Keywords: pp
Hardware: HP → All
Summary: Linux doesn't display window opened via window.open() → Linux doesn't display window opened via window.open() or target anchor attribute
You've probably noticed this also but after posting my last comment I tried to shut down the browser and had to ctrl+c out of it, presumeably because of the remaining windows that I hadn't closed because I couldn't see them. Also, I saw this while running 2001052209 on Linux.
Doesn't sound like a security problem. If it were, the window object wouldn't get created and you'd see an exception in the JS console. I'll trace into it and see if I can figure out what component to assign this to.
I think the weirdness started surfacing a couple of days before this bug. On Linux build ID 2001052006 the chain of events was different than before. Before the 20th (i believe) the news-links at http://www.linuxcentral.com spawned a new window immediately. Then i would see "resolving host" in status-bar, then the connection succeeding, and content started pouring in, rendering visibly in the window. In 2001052006 it takes a long time before the window spawns. All content arrives via modem *before* the window is at all created. When it finally IS created, it is complete, with all content rendered and in place, and modem-lights go quiet.
A workaround for this appears to be right clicking on the link and choosing "Open link in new window." At least this worked for me at http://mail.yahoo.com and http://www.progeny.com (on the news links).
Is this bug 79140 ?
Not sure... I just upgraded to 2001052309 and I'm not seeing this bug anymore... can anyone else still repro?
linux 2001052306: bug gone here too.. whatever this is a dup of, it seems fixed. WFM.
Hmmm, my bookmarks weren't showing up in the sidebar and I was getting duplicate entries in bookmark/back/forward menus so I started with a new profile and now thos problems are fixed but I'm seeing the bug again. dark, could you test this?
Pretty much the same thing happened here. There's something funny going on with the rdf files. It affects passwords too. I now see this bug again with the same build i former saw it work OK in. I also saw the missing bookmarks in sidebar, the double menu, and in addition there's password horkage going on in mail when i switch to the CVS build. I'll poke around in old profile files to see what is handled differently between those builds, but want to clobber first.
I had two instances of mozilla running, which can explain some mishaps. The bug is still alive both in current CVS and 2001052306. My CVS is gcc2.96RH but i like that compiler more and more ;)
Duplicate entries (actually they are doubled up) in Personal Toolbar bookmarks and forward/back history is covered in another bug. This bug covers new windows being opened using target="foo" in anchors and window.open Javascript. Both of these issues are still BROKEN in my build of cvs from today. This bug is still well and truely in existance.
Is Docshell the correct component, maybe?
Assignee: mstoltz → adamlock
Component: Security: General → Embedding: Docshell
QA Contact: ckritzer → adamlock
I was looking at bug 79140 and the testcase for that bug (http://justchat4.medium.net:4000/chat/test/mozilla/formSubmit/index.html) appears to exhibit the same behavior as this bug (except that that one causes a save to disk dialog to appear, which I thought was weird). Also, I tried another testcase mentioned in that bug: typing javascript: window.open("", "mywindow"); into the url bar and got the same behavior but also got the following message in the browser window: "[xpconnect wrapped window]" which may or may not be normal???
this seems related to bug 73893, but i never saw it till on morning 22nd.
I do not think this is Linux only problem. Mac OS trunk builds show this kind of behavior pretty often. The tendency varies between the daily builds, though.
OS: Linux → All
Summary: Linux doesn't display window opened via window.open() or target anchor attribute → Linux and Mac don't display window opened via window.open() or target anchor attribute
Users are accustomed to the app will terminate when the last window is closed with the X button. But if there are hidden windows, the last visible window won't quit mozilla. I imagine people don't reflect too much about "that link that didn't work" and go on surfing. Then, when they close the last visble window, they find that Mozilla didn't actually quit - and bugs like 82722 are filed. (Windows).
Is it OK to dupe this to bug 79140?
Why? This bug didn't happen till around midnight 22nd, while 79140 was reported with a build from May 3rd. Furthermore.. this doesn't cause a hang. 79140 was a hang, and most say "WFM" now. They seem to be two different bugs.
Rick, is this something to do with your recent window targetting changes?
Assignee: adamlock → rpotts
in 2001052508 trunk for Mac, the URL WFM. So does bug 79140.
Linux 2001-05-28-08: the given URL opens a new window and displays the about: page. WFM?
Would you mind testing the duplicate as well? Bug 82095
The duplicate also works for me in Linux 2001-05-28-08 trunk.
The URL link here still does not work in my linux build from today's tip.
I'm still seeing this on 2001052809/Linux at http://mail.yahoo.com (clicking on link inside message) among other places.
rpotts: considering this could be a stop-ship, please at least take a look and evaluate this for 0.9.1 timeframe. Adding asa for drivers.
WFM on Mac, build 2001052808
2001052808 linux SEA: new windows do not open when clicking at news-stories at linuxcentral.com RH7.1, KDE2.1.1/2.1.2, XFree86 4.0.3. Tried old profile and even a new as root. No go.
That is really queer. Everything works fine on my usual profile, but with a fresh profile, the given URL and cited testcases do NOT work. So I guess this really is a bug and the difference between seeing it and not seeing it is in the profile somewhere.
Reassigning to Networking: cache. The problems go away if I go to preferences/debug and disable the disk cache.
Assignee: rpotts → gordon
Component: Embedding: Docshell → Networking: Cache
QA Contact: adamlock → tever
This is a weird bug. Now i got a window to open. It takes a long while, and the only indication something is loading is modem lights. When the new window opened, everything was finished rendering in it. Not sure i trust my own eyes here anymore.
bug 82969 may be another variant of this bug.
in a current linux CVS build this now works again - new windows open. Tested linuxcentral, playboy site and progeny. (Several times to see if cache was involved.) In all cases windows now open, and THEN content renders - and that's how it should be.
They work on my current linux cvs build too. Can someone check other OS/Platforms please.
Okay, I've tested this on: -MacOS91 2001-06-01-08-trunk -Win98SE 2001-06-01-06-trunk -LinRH62 2001-06-01-08-trunk and it WFM on all three platforms. I'm gonna mark this WORKSFORME...
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Marking VERIFIED WORKSFORME on: -MacOS91 2001-06-01-08-trunk -Win98SE 2001-06-01-06-trunk -LinRH62 2001-06-01-08-trunk If you disagree, reopen.
Status: RESOLVED → VERIFIED
Reopening. This has returned in 2001060114 trunk for Mac.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
The JS in the URL field still works in my Linux build pulled from the tip this morning (08:25:45 BST).
Disabling the disk cache may perturb timing, but it shouldn't have anything to do with whether windows appear or not. Assigning to docshell, as Mitch Stoltz suggested on 5/23.
Assignee: gordon → adamlock
Status: REOPENED → NEW
Component: Networking: Cache → Embedding: Docshell
QA Contact: tever → adamlock
I'm using 2001060114 trunk on the mac and it worksforme. What gives?
I have realized that this fails in the second occasion after the window initially opened has been closed. I assume that it also fails when there has been an unrelated target window opened and closed, then this URL is clicked. I can confirm that it worked at the first try, but failed at the second try.
On further observation, I have noticed that this URL fails if this bug is opened in the first window, but works if opened in the second window as in bug 83632.
javascript:void(window.open("about:")); now works for me. Anyone seeing this bug with latest builds?
Marking WORKSFORME
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.