"base target" non-functional

RESOLVED WORKSFORME

Status

SeaMonkey
General
RESOLVED WORKSFORME
15 years ago
12 years ago

People

(Reporter: Joachim Schlosser, Assigned: asa)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.2.1) Gecko/20021130

When specifying a "base target" header tag for a page, it does not change the
links' behavior.
Example: 
    <base target="_blank">
Should open each link of the page in a new window, but it does not.


Reproducible: Always

Steps to Reproduce:
1. create page with <base target="_blank"> in header.
2. add a link to this page
3. click on the link

Actual Results:  
Does not open a new window.

Expected Results:  
Open a new window.

I checked the 3 bugs shown when searching for "base target", but seems not to
interfere.
(Reporter)

Comment 1

15 years ago
possibly related to #67893?
Testcase works for me, linux trunk build 2003-03-03-05.  Is this a problem with
a recent build?  Please attach a testcase that fails?
(Reporter)

Comment 4

15 years ago
Yes, your testcase fails on my box.
First I thought I had made some mistake with configuration (Scripts & Plugins
->"open unwanted windows" or whatever it's called in English), but that has no
effect.
I extensively searched bugzilla and google before submitting this bug, but have
no clue.
Do you have the hidden pref for disabling window targets set?  This used to have
UI but no longer does; you'll need to search your prefs file for "target".
(Reporter)

Comment 6

15 years ago
The only line containing "target" in my prefs.js is

user_pref("browser.block.target_new_window", false);

and this has a UI.
Hmm.... Does a clean profile also show the problem for you?
umm. Joachim, where does that pref have UI?

According to
http://lxr.mozilla.org/seamonkey/search?string=target_new_window
that pref has no UI at all.

I would think that exactly that line is the problem.
(Reporter)

Comment 9

15 years ago
Wow, I thought I was save, because I could reproduce it on another machine. But
this morning, on a third one (at work), it works as it should.
In fact, at home I have the 

user_pref("browser.block.target_new_window", false);

line in my profile. Here, on the machine where it is working I don't.
I'll keep on trying at home and report if I can find the reason. The cause may
be that I upgraded Mozilla from an older version at home while keeping the profile.
(Reporter)

Comment 10

15 years ago
I solved it. There were two mistakes on my side:
1. I used an old prefs.js where the value was set to true. It now does not have
a UI any more.
2. When testing setting it to false, I did not kill the tray icon of Mozilla, so
it did not read the changed value from the file. A misunderstanding on my side.

I now killed the Mozilla process, changed the value to false and now it works.
Thank's to you very much and sorry for wasting your time!

Joachim
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 11

15 years ago
Reopening to resolve properly.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---

Comment 12

15 years ago
-> WORKSFORME as per comment 10.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.