Closed
Bug 82159
Opened 24 years ago
Closed 23 years ago
Linux and Mac don't display window opened via window.open() or target anchor attribute
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ckritzer, Assigned: adamlock)
References
()
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.
Comment 1•24 years ago
|
||
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
Comment 3•24 years ago
|
||
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?
Reporter | ||
Comment 4•24 years ago
|
||
The testcase is an internal link only. Changing back to HP/Linux.
OS: All → Linux
Hardware: All → HP
Reporter | ||
Comment 5•24 years ago
|
||
Changing summary
Summary: opening new windows via target or window.open doesn't work → Linux doesn't display window opened via window.open()
Comment 6•24 years ago
|
||
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?
Reporter | ||
Comment 7•24 years ago
|
||
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 :-\
Reporter | ||
Comment 9•24 years ago
|
||
Hmm, noticed the creation-and-not-displayed-ness of the windows, but didn't
catch the leaks. Good job, Dave.
Comment 10•24 years ago
|
||
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
Comment 11•24 years ago
|
||
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.
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
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).
Comment 15•24 years ago
|
||
Is this bug 79140 ?
Comment 16•24 years ago
|
||
Not sure... I just upgraded to 2001052309 and I'm not seeing this bug anymore...
can anyone else still repro?
Comment 17•24 years ago
|
||
linux 2001052306: bug gone here too.. whatever this is a dup of, it seems fixed.
WFM.
Comment 18•24 years ago
|
||
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?
Comment 19•24 years ago
|
||
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.
Comment 20•24 years ago
|
||
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 ;)
Comment 21•24 years ago
|
||
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.
Comment 22•24 years ago
|
||
Is Docshell the correct component, maybe?
Assignee: mstoltz → adamlock
Component: Security: General → Embedding: Docshell
QA Contact: ckritzer → adamlock
Comment 23•24 years ago
|
||
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???
Comment 24•24 years ago
|
||
this seems related to bug 73893, but i never saw it till on morning 22nd.
Comment 25•24 years ago
|
||
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
Comment 26•24 years ago
|
||
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).
Comment 27•24 years ago
|
||
Is it OK to dupe this to bug 79140?
Comment 28•24 years ago
|
||
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.
Assignee | ||
Comment 29•24 years ago
|
||
Rick, is this something to do with your recent window targetting changes?
Assignee: adamlock → rpotts
Comment 30•24 years ago
|
||
in 2001052508 trunk for Mac, the URL WFM. So does bug 79140.
Comment 31•24 years ago
|
||
Linux 2001-05-28-08: the given URL opens a new window and displays the about:
page. WFM?
Comment 32•24 years ago
|
||
Would you mind testing the duplicate as well? Bug 82095
Comment 33•24 years ago
|
||
The duplicate also works for me in Linux 2001-05-28-08 trunk.
Comment 34•24 years ago
|
||
The URL link here still does not work in my linux build from today's tip.
Comment 35•24 years ago
|
||
I'm still seeing this on 2001052809/Linux at http://mail.yahoo.com (clicking on
link inside message) among other places.
Comment 36•24 years ago
|
||
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.
Assignee | ||
Comment 37•24 years ago
|
||
WFM on Mac, build 2001052808
Comment 38•24 years ago
|
||
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.
Comment 39•24 years ago
|
||
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.
Comment 40•24 years ago
|
||
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
Comment 41•24 years ago
|
||
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.
Comment 42•24 years ago
|
||
bug 82969 may be another variant of this bug.
Comment 43•24 years ago
|
||
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.
Comment 44•24 years ago
|
||
They work on my current linux cvs build too.
Can someone check other OS/Platforms please.
Reporter | ||
Comment 45•23 years ago
|
||
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: 23 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 46•23 years ago
|
||
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
Comment 47•23 years ago
|
||
Reopening.
This has returned in 2001060114 trunk for Mac.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Comment 48•23 years ago
|
||
The JS in the URL field still works in my Linux build pulled from the tip this
morning (08:25:45 BST).
Comment 49•23 years ago
|
||
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
Assignee | ||
Comment 50•23 years ago
|
||
I'm using 2001060114 trunk on the mac and it worksforme. What gives?
Comment 51•23 years ago
|
||
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.
Comment 52•23 years ago
|
||
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.
Comment 53•23 years ago
|
||
javascript:void(window.open("about:")); now works for me. Anyone seeing this bug
with latest builds?
Assignee | ||
Comment 54•23 years ago
|
||
Marking WORKSFORME
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•