Closed
Bug 172202
Opened 23 years ago
Closed 23 years ago
target="_blank" in a link (<A>) does not spawn a new Window
Categories
(SeaMonkey :: General, enhancement)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: tuttle_james, Assigned: john)
References
()
Details
Accordint to the W3C's HTML 4 spec
(http://www.w3.org/TR/html4/types.html#type-frame-target), links with
'target="_blank"' should spawn a new window. Mozilla 1.2a does not do this, but
loads the link in the same window.
The URL provided (http://www.w3.org/TR/html4/types.html#type-frame-target)
provides a bare-bones Test Case.
Comment 1•23 years ago
|
||
Do you per chance run Privoxy (Internet Junkbuster) or another proxy? Does it
say 'target="_blank"' (unmodified) or 'notarget' (modified by proxy) in the
testcase source?
| Reporter | ||
Comment 2•23 years ago
|
||
I am behind a proxy here at work, so I haven't tried it without a proxy.
However, a "View Source" on that page, shows the HTML exactly as I coded it
(target="_blank"), which Validates just fine.
Comment 3•23 years ago
|
||
And you have not turned on the preference to disable target="_blank" I assume?
(look for the string "target" in your prefs.js)
The testcase you point to seems to work fine for me; Linux build 2002-09-30-21.
Comment 4•23 years ago
|
||
I had the same problem and then I discover that my prefs.js contained a line
user_pref("browser.block.target_new_window", true);
Changing it to false resolved the problem. I believe there was an option in
Edit/Preferences to turn on this feature that isn't anymore in Mozilla 1.1 GUI.
I still miss a feature to force such links to open in new tabs.
| Reporter | ||
Comment 5•23 years ago
|
||
I've found the line in prefs.js that was mentioned by a couple folks.
Great, I can fix my problem. :-)
However, I still think that it's a bug. Mozilla's out-of-the-box behavior is
not W3C-compliant. Even if there was a GUI interface to this preference, the
default behavior should be compliant.
Comment 6•23 years ago
|
||
the mentioned setting is not the default.
marking WORKSFORME.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
| Reporter | ||
Comment 7•23 years ago
|
||
C'mon!
"The mentioned setting is not the default"?!?
Mozilla goes to great pains to be W3C HTML4 compliant. Why would the default
behavior (change-able only through an non-user-friendly prefs file!) for
something like this CHOOSE to be non-compliant!
Please make the default behavior compliant.
Jim
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 8•23 years ago
|
||
I meant
the default behaviour is what you want
disabling new windows for links is not the default.
marking WFM again.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Comment 9•23 years ago
|
||
Jim, that preference used to have UI. You must have set it when it did so. The
UI has since been removed.
The default setting is most emphatically "false" for that preference.
| Reporter | ||
Comment 10•23 years ago
|
||
After upgrading to Mozilla 1.2b, this problem is back. I had to manually go
into my prefs.js and change "browser.block.target_new_window" back to "false".
Any idea what in the upgrade process (or some other part of Mozilla) could be
changing this "hidden" preference? I most certainly have not been going into my
prefs and accidently causing these changes...
I'm not trying to be a pain in the $%^ here - I think that there's a real bug
here....
Status: RESOLVED → UNCONFIRMED
Component: Layout: HTML Frames → Browser-General
Resolution: WORKSFORME → ---
Comment 11•23 years ago
|
||
Hmm. Jim, how are you installing Mozilla exactly? Step by step.
| Reporter | ||
Comment 12•23 years ago
|
||
I downloaded the Win32 Talkback-enabled release from
http://www.mozilla.org/releases/.
Ran the executable - took all defaults, except for the install of Chatzilla,
Mail, or News.
Then, I run Mozilla normally (no options).
I have installed other items like Netscape 7 and Phoenix since installing
Mozilla 1.2b. Could they be "trashing" my preferences?
Comment 13•23 years ago
|
||
not inconceivable, especially if you ever run Netscape 7 and mozilla at the same
time using the same profile. Phoenix does not conflict with those, however.
| Reporter | ||
Comment 14•23 years ago
|
||
I've run Mozilla, Netscape7, and Phoenix multiple times sequentially, and I
can't get it to reproduce.
Interestingly, though, if I add:
user_pref("browser.block.target_new_window", true);
by hand, it sticks in the prefs file.
If I set the value to "false", Mozilla deletes the whole line from the prefs the
next time it generates it.
Since this is a hidden (undocumented?) "feature" (and something else is going in
and periodically setting this one me!), could we either get a direct GUI item
for this in the Preferences Panel, or have Mozilla always delete (or ignore)
this line item in the prefs file?
Thanks!
| Reporter | ||
Comment 15•23 years ago
|
||
I did a massive recursive grep thru the Mozilla source code (hey, I'm a hack),
and I can see calls to:
GetBoolPref("browser.block.target_new_window", &blockNewWindow)
and to:
pref("browser.block.target_new_window", false)
But no where can I see a statement of the 2nd form where this pref is set to
TRUE. So, something else other than Mozilla is clobbering this value. Could be
one of the add-ons (leech, etc.) for some reason, or even Netscape 7.
So, I no longer consider the CAUSE a Mozilla bug. However, I still would to see
this Pref get a GUI, or be dropped entirely. I'm moving this to "Enhancement",
and maybe it will be picked up someday (or someone can close it, if they really
want to get rid of it).
Thanks.
Severity: minor → enhancement
Comment 16•23 years ago
|
||
Jim, please file a new bug for your suggestion in comment 15.
this bug is INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•