Closed
Bug 17468
Opened 25 years ago
Closed 25 years ago
[WebShell] links w/target attribute do not create new window when clicked
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: ckritzer, Assigned: mscott)
References
Details
(Keywords: regression, Whiteboard: [PDT+][NEED INFO])
Attachments
(2 files)
Overview Description: When a link which has a target attribute set is clicked,
there is no new window generated for the url to load into. (It doesn't load
into the current window either, but that's expected behaviour.)
Steps to Reproduce:
1) Launch apprunner.
2) Download the attached file and load it into apprunner:
3) Click on the first link and it will not create a new browser window (the
second link is simply for reference.)
Actual Results: No new browser window is created.
Expected Results: New browser window created and url loaded into it.
Build Date & Platform Bug Found:
Win98 19992808 apprunner
Linux6 19992808 apprunner
MacOS 19992810 apprunner
Additional Builds and Platforms Tested On:
|
Reporter | |
Comment 1•25 years ago
|
||
Fixed, I tried to attach the diff to this bug several times but it never
showd up in the bug so I'm including it here. Joki, does this look OK, will
you check this in or should I? IMO this should go into M12.
Thanks to tor@cs.brown.edu for making me aware of this and for helping fixing
this...
Index: webshell/src/nsWebShell.cpp
===================================================================
RCS file: /cvsroot/mozilla/webshell/src/nsWebShell.cpp,v
retrieving revision 1.293
diff -u -r1.293 nsWebShell.cpp
--- nsWebShell.cpp 1999/11/06 03:37:32 1.293
+++ nsWebShell.cpp 1999/11/07 01:21:14
@@ -2942,7 +2942,7 @@
if (name.EqualsIgnoreCase("_blank")) {
nsIWebShell *shell;
- if (NS_OK == NewWebShell(PRUint32(~0), PR_TRUE, shell))
+ if (NS_OK == NewWebShell(NS_CHROME_ALL_CHROME, PR_TRUE, shell))
target = shell;
else
{
Index: xpfe/appshell/src/nsWebShellWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,v
retrieving revision 1.226
diff -u -r1.226 nsWebShellWindow.cpp
--- nsWebShellWindow.cpp 1999/11/06 03:39:23 1.226
+++ nsWebShellWindow.cpp 1999/11/07 01:21:21
@@ -1612,8 +1612,13 @@
nsIAppShell *subshell;
if (NS_SUCCEEDED(rv)) {
nsCOMPtr<nsIBrowserWindow> browser(do_QueryInterface(newWindow));
- if (browser)
+ if (browser) {
browser->SetChrome(aChromeMask);
+
+ if (aVisible) {
+ browser->ShowAfterCreation();
+ }
+ }
// Spin into the modal loop.
rv = nsComponentManager::CreateInstance(kAppShellCID, nsnull,
kIAppShellIID, (void**)&subshell);
Whiteboard: Fixed
Summary: links w/target attribute do not create new window when clicked → [WebShell] links w/target attribute do not create new window when clicked
|
||
Comment 9•25 years ago
|
||
|
||
Comment 11•25 years ago
|
||
|
|
||
Comment 12•25 years ago
|
||
Just tested some more, 19510 is a dup, the links do work, my mistake. I'm
marking both 19510 and 8470 as dups of this!
|
|
||
Comment 13•25 years ago
|
||
*** Bug 19510 has been marked as a duplicate of this bug. ***
|
|
||
Comment 14•25 years ago
|
||
*** Bug 8470 has been marked as a duplicate of this bug. ***
|
||
Comment 15•25 years ago
|
||
I tested all the attachments below and things seem to be working just fine.
I noticed the status whiteboard shows Fixed, but not the plain status option it
still says NEW.
|
||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
||
Comment 16•25 years ago
|
||
I agree, should be marked fixed.
|
||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
|
|
||
Comment 17•25 years ago
|
||
Fixed in the Dec 22 build (1999122208).
|
||
Comment 18•25 years ago
|
||
This bug reappeared in the 1/15 nightly builds (reportedly) and in my cvs pull
from 1/16 on solaris/native. The behavior is somewhat different than before:
* ./mozilla-bin http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3052
* click on the first link ("target=_blank"). No window is created, and the
following messages are printed:
WEBSHELL+ = 4
nsXULKeyListenerImpl::Init()
WARNING: unable to load datasource 'rdf:xpinstall-update-notifier', file
/cs/src/mozilla/mozilla/rdf/content/src/nsXULDocument.cpp, line 5157
WEBSHELL+ = 5
title string = [Mozilla]
* File->Exit. During shutdown another window pops up (the new browser
window?), but is removed before drawing anything.
|
|
||
Comment 19•25 years ago
|
||
Fixed by waterson's checkin 1.32 of nsChromeProtocolHandler.cpp to fix 24144.
|
|
||
Comment 21•25 years ago
|
||
Reappeared in a 2/12 cvs pull on solaris/native. Steps to reproduce:
* ./mozilla-bin http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3052
* click on the first link ("target=_blank"). No window is created, and the
following messages are printed:
WEBSHELL+ = 5
Skipping libstreamconv.so, already read
assuming d&d is off for Navigator
WARNING: unable to load datasource 'rdf:xpinstall-update-notifier', file
/cs/src/mozilla/mozilla/rdf/content/src/nsXULDocument.cpp, line 5240
WEBSHELL+ = 6
WEBSHELL+ = 7
Setting content window
browser.startup.page = 1
startpage = http://www.mozilla.org/
got a request
Document http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3052 loaded
successfully
Document: Done (1.743 secs)
* File->Exit. During shutdown another window pops up (the new browser
window?), but is removed before drawing anything.
|
||
Comment 23•25 years ago
|
||
Yes this happens on Linux.
|
|
||
Comment 24•25 years ago
|
||
Sorry forgot to mention that this is in the Feb 14th build (Linux).
|
|
||
Comment 25•25 years ago
|
||
This was broken even more yesterday, mscotts checkin to nsWebShell broke it
even more, now the new webshell isn't found even if it's available (ie a
frameset document) nor is any new webshells created. mscott is aware of this
and he said that he's working on it.
|
|
||
Comment 26•25 years ago
|
||
*** Bug 27937 has been marked as a duplicate of this bug. ***
|
Assignee | |
Comment 27•25 years ago
|
||
Travis and I broke this yesterday. I have a fix in my tree ready to go. If I
click on the target=_blank example, I now see a new blank window come up
(actually the default page is getting loaded into it right now)
I'll try to get it reviewed and checked in tonight.
re-assigning to me..
Assignee: joki → mscott
Status: REOPENED → NEW
|
|
Assignee | |
Comment 28•25 years ago
|
||
I checked the fix in for this. In addition I fixed _new so we now properly
create a new window.
As far as I could tell all the target tests on that example web page worked for
me. Although I did notice that _blank brings up a new window but it loads the
default web page into the window which it probably shouldn't. But that can be in
another non PDT+ bug.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Target Milestone: M14
|
|
||
Comment 29•25 years ago
|
||
Target names _blank, _self, _parent, _top, and _new all work for me in the Feb
18th build. The testcase provided in the first attachment uses a target name of
"mozilla". This is not a reserve target name.
|
|
||
Comment 30•25 years ago
|
||
Target names _blank, _self, _parent, _top, and _new all work for me in the Feb
18th build. The testcase provided in the first attachment uses a target name of
"mozilla". This is not a reserve target name.
|
|
Assignee | |
Comment 31•25 years ago
|
||
links
with
targets
that
havea
nonreserver
targetname
andneeda
newwindow
iscovered
inPDt+bug
#27419
Ihaveafixwaitingforreview
forthatbug
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout
You need to log in
before you can comment on or make changes to this bug.
Description
•