Change existing link's href - weird IE bug.

[automatyk]

I need to change an href on an existing link in my document depending
on some user input.
I was able to get this to work in Firefox, but the behavior in IE is
troubling. The new link works in both browsers, however, IE rewrites
the entire link text! This is my code:

<script type="text/javascript">
function getContractNum() {
var cNum = document.forms[0].contractNum.value;
var cNum1 = document.forms[0].contractNum1.value;
var cComplete;
if (cNum != '') {
subjectline = cNum;
} else if (cNum1 != '') {
subjectline = cNum1;
} else {
subjectline = 'x';
}

var newlink = 'mailto:[email protected]?subject=Rep Payee%20:%20' +
subjectline;
var target = document.getElementById("dynamicsubject");
target.setAttribute('href', newlink);
}
</script>

My HTML contains a form with a couple of inputs and a link.

<a id="dynamicsubject" href="mailto://[email protected]">Click here to
send email.</a>

Firefox behaves as you'd expect... the href is changed and the link
text is the same.
Internet Explorer however displays:
mailto:[email protected]?subject=Rep Payee%20:%20x

The link works in both cases! Can anyone help me figure this out?
It's been driving me crazy all day!

Thanks.

 

[Doug Gunnoe]

I need to change an href on an existing link in my document depending
on some user input.
I was able to get this to work in Firefox, but the behavior in IE is
troubling.  The new link works in both browsers, however, IE rewrites
the entire link text!  This is my code:

<script type="text/javascript">
        function getContractNum() {
                var cNum = document.forms[0].contractNum..value;
                var cNum1 = document.forms[0].contractNum1.value;
                var cComplete;
                if (cNum != '') {
                        subjectline = cNum;
                } else if (cNum1 != '') {
                        subjectline = cNum1;
                } else {
                        subjectline = 'x';
                }

                var newlink = 'mailto:[email protected]?subject=Rep Payee%20:%20' +
subjectline;
                var target = document.getElementById("dynamicsubject");
                target.setAttribute('href', newlink);
        }
</script>

My HTML contains a form with a couple of inputs and a link.

<a id="dynamicsubject" href="mailto:/[email protected]">Click here to
send email.</a>

Firefox behaves as you'd expect... the href is changed and the link
text is the same.
Internet Explorer however displays:
mailto:[email protected]?subject=Rep Payee%20:%20x

The link works in both cases!  Can anyone help me figure this out?
It's been driving me crazy all day!

Thanks.

Have you tried to do target.href = newLink instead of using
setAttribute?

 

[Thomas 'PointedEars' Lahn]

I need to change an href on an existing link in my document depending
on some user input.
I was able to get this to work in Firefox, but the behavior in IE is
troubling. The new link works in both browsers, however, IE rewrites
the entire link text! [...]
My HTML contains a form with a couple of inputs and a link.

<a id="dynamicsubject" href="mailto://[email protected]">Click here to
send email.</a>

Firefox behaves as you'd expect... the href is changed and the link
text is the same.
Internet Explorer however displays:
mailto:[email protected]?subject=Rep Payee%20:%20x

WFM in

- Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;
{3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 2.0.50727)

- Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
{3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 2.0.50727)
(standalone)

- Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.1;
{3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 2.0.50727)
(standalone)

Please post a public URL of your test case.


PointedEars

 

[automatyk]

Thanks for the input everyone!

Unfortunately, my site is on a corporate intranet so I cannot post a
link. (FTP is locked down as well :-( )
I've tried the "target.href = newLink" method - it behaves the same.

I'll rename the "target" variable to see if that's the issue. If that
fails, however, I'll assume that the corporate branded IE7 is the
culprit.

I'll post a solution if I solve the problem.

I need to change an href on an existing link in my document depending
on some user input.
I was able to get this to work in Firefox, but the behavior in IE is
troubling. The new link works in both browsers, however, IE rewrites
the entire link text! [...]
My HTML contains a form with a couple of inputs and a link.

<a id="dynamicsubject" href="mailto:/[email protected]">Click here to
send email.</a>

Firefox behaves as you'd expect... the href is changed and the link
text is the same.
Internet Explorer however displays:
mailto:[email protected]?subject=Rep Payee%20:%20x

WFM in

- Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;
{3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 2.0.50727)

- Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
{3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 2.0.50727)
(standalone)

- Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.1;
{3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 2.0.50727)
(standalone)

Please post a public URL of your test case.

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <[email protected]>

 

[Dr J R Stockton]

Why do people have such a hard time posting code indented with spaces
and not tabs?

Because the matter is not mentioned in section 2,3 if the FAQ which you
supposedly maintain?

 

[The Natural Philosopher]

Thanks for the input everyone!

Unfortunately, my site is on a corporate intranet so I cannot post a
link. (FTP is locked down as well :-( )
I've tried the "target.href = newLink" method - it behaves the same.

I'll rename the "target" variable to see if that's the issue. If that
fails, however, I'll assume that the corporate branded IE7 is the
culprit.

I'll post a solution if I solve the problem.

Why not sidestep it, make the URL a dummy (text only) and use onclick()
to generate a window.open thing?

Either you are trying to avoid javascript like the plague, or you are
using it because you must. In which case use it. In the most browser
independent way.

I need to change an href on an existing link in my document depending
on some user input.
I was able to get this to work in Firefox, but the behavior in IE is
troubling. The new link works in both browsers, however, IE rewrites
the entire link text! [...]
My HTML contains a form with a couple of inputs and a link.
<a id="dynamicsubject" href="mailto:/[email protected]">Click here to
send email.</a>
Firefox behaves as you'd expect... the href is changed and the link
text is the same.
Internet Explorer however displays:
mailto:[email protected]?subject=Rep Payee%20:%20x

WFM in

- Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;
{3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 2.0.50727)

- Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
{3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 2.0.50727)
(standalone)

- Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.1;
{3E1C4754-F096-BBFE-CD76-3B2E8F19E202}; .NET CLR 2.0.50727)
(standalone)

Please post a public URL of your test case.

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <[email protected]>

 

[Thomas 'PointedEars' Lahn]

I need to change an href on an existing link in my document depending on
some user input. I was able to get this to work in Firefox, but the
behavior in IE is troubling. The new link works in both browsers,
however, IE rewrites the entire link text! This is my code:

I see two irregularities in your code:

[...]
var newlink = 'mailto:[email protected]?subject=Rep Payee%20:%20' +
subjectline;

There is a space character in the mailto: URI that was not escaped with
`%20'. URIs must not contain unescaped spaces.

[...]
<a id="dynamicsubject" href="mailto://[email protected]">Click here to
send email.</a>

mailto: is a URI, not a URL. Remove the `//'.

That said, you should not use `mailto:' URIs as it requires a local e-mail
client, and a user agent that has it set as handler for those URIs. Set a
link to a form-mailer instead.


HTH

PointedEars

 

[automatyk]

Thomas,

I am trapped in corporate intranet land where I don't have the luxury
of access to code things properly. Everything is an ordeal. I can
have javascript! That's all. Thanks for catching the space issue.

Company wide, we've got IE7 and Outlook. That's all we're officially
supposed to support. I'm still puzzled by the setAttribute issue on
IE7. FF works just fine.

-G

I need to change an href on an existing link in my document depending on
some user input. I was able to get this to work in Firefox, but the
behavior in IE is troubling. The new link works in both browsers,
however, IE rewrites the entire link text! This is my code:

I see two irregularities in your code:

[...]
var newlink = 'mailto:[email protected]?subject=Rep Payee%20:%20' +
subjectline;

There is a space character in the mailto: URI that was not escaped with
`%20'. URIs must not contain unescaped spaces.

[...]
<a id="dynamicsubject" href="mailto:/[email protected]">Click here to
send email.</a>

mailto: is a URI, not a URL. Remove the `//'.

That said, you should not use `mailto:' URIs as it requires a local e-mail
client, and a user agent that has it set as handler for those URIs. Set a
link to a form-mailer instead.

HTH

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

 

[Thomas 'PointedEars' Lahn]

I am trapped in corporate intranet land where I don't have the luxury
of access to code things properly. Everything is an ordeal. I can
have javascript! That's all.

Please don't play stupid, you are insulting the intelligence of your readers.

Since you can post here via Google Groups, it is possible for you
to get access to some freely available reference material like
<http://rfc-editor.org/rfc/rfc3986.txt> and
<http://rfc-editor.org/rfc/rfc2368.txt>

And although it certainly helps, you don't *need* an IDE to write proper
code, only Brain 1.0.

Thanks for catching the space issue.

You're welcome. Don't forget to fix the `//' issue, and thanks for proper
quoting next time:

[...]
[full quote]

http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1Post


PointedEars

 

[automatyk]

Please don't play stupid, you are insulting the intelligence of your readers.

A little harsh maybe? A couple tiny mistakes do not warrant such a
statement.

My "trapped in corporate intranet land" comment isn't an excuse to
write bad code. I'm not implying that. I'm simply stating that due
to the fact that I'm locked out of any server side language and locked
out of many resources most programmers take for granted, I am forced
to come up with bastardized solutions from time to time. Forgive me.

Good day.

I am trapped in corporate intranet land where I don't have the luxury
of access to code things properly. Everything is an ordeal. I can
have javascript! That's all.

Please don't play stupid, you are insulting the intelligence of your readers.

Since you can post here via Google Groups, it is possible for you
to get access to some freely available reference material like
<http://rfc-editor.org/rfc/rfc3986.txt> and
<http://rfc-editor.org/rfc/rfc2368.txt>

And although it certainly helps, you don't *need* an IDE to write proper
code, only Brain 1.0.

Thanks for catching the space issue.

You're welcome. Don't forget to fix the `//' issue, and thanks for proper
quoting next time:

[...]
[full quote]

http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1Post

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <[email protected]>

 

[Thomas 'PointedEars' Lahn]

Please don't remove the attribution line, it is important for following the
discussion. Shorten it to the name of the poster of the precursor, if you wish.

A little harsh maybe? A couple tiny mistakes do not warrant such a
statement.

"Playing stupid" means to pretend to know less that one could know, given
the circumstances.

My "trapped in corporate intranet land" comment isn't an excuse to
write bad code. I'm not implying that. I'm simply stating that due
to the fact that I'm locked out of any server side language and locked
out of many resources most programmers take for granted, I am forced
to come up with bastardized solutions from time to time. Forgive me.

You should have mentioned that explicitly in the first place. No offense
was meant, though.

[Top posting again]

That is also what I mean when I say playing stupid. You *know*, at least as
you have been told before now, that a full quote at the bottom of your
posting is not appropriate in Usenet in general, and here in particular.
But you do it anyway. What impression, do you think, gives that to your
readers?


Score adjusted

PointedEars

 

[automatyk]

That is also what I mean when I say playing stupid. You *know*, at least as
you have been told before now, that a full quote at the bottom of your
posting is not appropriate in Usenet in general, and here in particular.
But you do it anyway. What impression, do you think, gives that to your
readers?

How could such a tragedy have been prevented? Perhaps posting a
permanent link to the FAQ on the home page of your group! Is that
possible? I was not aware of the "rules" until after committing these
heinous crimes against USENET in general and comp.lang.javascript in
particular. Extracting the most important "rules" into a document
that could be quickly scanned would also help.

As an aside, my corporate IE7 continues to behave as I've described
originally. The code works perfectly fine in FF and Safari. I'm
going to assume this is just a fluke restricted to my corporate
environment.

function getContractNum() {
var cNum = document.forms[0].contractNum.value;
var cNum1 = document.forms[0].contractNum1.value;

if (cNum != '') {
subjectline = cNum;
} else if (cNum1 != '') {
subjectline = cNum1;
} else {
subjectline = 'x';
}

var theTarget = document.getElementById("dynamicsubject");
var existingHref = document.getElementById("dynamicsubject").href;
var newlink = existingHref + '?subject=Rep%20Payee%20:%20' +
subjectline;
theTarget.setAttribute('href', newlink);
}

The function is called by a select drop down, and references a link:
<a id="dynamicsubject" href="mailto:[email protected]">Send an email
attachment</a>

 

[Dr J R Stockton]

Dr J R Stockton said the following on 1/17/2008 11:37 AM:

Probably because nobody has requested it in a format that leads to it
getting added. Section 5 is there for a reason.

You are unusually weird for a FAQ maintainer : you lack confidence in
your own ability. That's not of itself a fault; but it ought to be an
error.

 

[Dr J R Stockton]

The fault lies in your ability to read, comprehend, and understand what
I agreed to do and did not agree to. This gets old after a while.

What you said was not agreed to by the newsgroup in general. Giving you
the power was a foolish mistake.

In your year or so of tenure you have achieved rather little, in spite
of a great deal of bluster.

 

[VK]

As an aside, my corporate IE7 continues to behave as I've described
originally. The code works perfectly fine in FF and Safari. I'm
going to assume this is just a fluke restricted to my corporate
environment.

at-sign is one of used to produce spoofed URLs in the address bar:
http://support.microsoft.com/kb/833786

This way I assume either IE7 recent security update or a 3rd party
security tool in effect: so it reinforces the suspicious path to be
displayed on the page for further user consideration.

I do understand you desire to save time and efforts by lurking with
mailto: pseudo-protocol instead of standard solution. Yet the
usability/reliability considerations should always prevail IMO.
Especially it is true for intranet coding where you will get a call to
your boss room in the same building, and not just a remote complain
from some regular user ;-)

So just do what all descent people do for the functionality you need:
write ASP/PHP/Perl server-side mailer and call it from your page as a
regular form submission providing necessary e-mail address, subject
and body.

 

[VK]

If you don't like the way I do it, the means to change it
are in your hands. I will email Jim and tell him to cancel my login,
give you one, and then you can edit it the way you see fit.

That would be an unhappy event for the NG, so I hope that you are not
serious on that. You are doing a good job.
If we could start a wiki with selected edit keys the benefit would be
great IMHO. Free Wiki hosting is largely available everywhere, so it
could be done upon agreement within a few hours for free.

 

[VK]

So, not sure if this possible or not (what I have in mind). You
have three levels of access:

1) Open access to post. Email driven subscription pretty much like
Google Groups uses (a lot of websites use that type of system), where it
sends you a confirmation email and then you can post.
OK

2) Access to create new areas.
OK

3) Server access. The people with server access would be able to cancel
accounts, modifyWikisettings on the server. Admin type things.

OK... kind of... In wikis frozen pages and canceled accounts is not a
casual thing. It is an extreme measure to prevent roll-back wars when
fighting side are unable to come to any NPOV (Neutral Point Of View)
text. Even if applied by service authorities, it is not a way to
enforce some "final result" but merely a way to force involved parties
to cool off and to bring their demands to some mutially acceptable
point. In Wikipedia it happens on some political / national issies,
but in a programming language? I may think of "Browsers_to_support" or
"Using_3rd_party_libraries" maybe. But it can be always resolved
by "Different points of view" section. Though who knows... OK

How about Wikihost.org ? To not be accused in Pan-Americanism I
have chosen a German service from tdb GmbH (http://www.tdb.de)

http://wikihost.org/wikis/javascript_faq/

http://wiki.wikihost.org/wiki/howto
http://wiki.wikihost.org/wiki/users_help_users

Is it anyhow satisfactory? If so I'm ready to email the admin log/pass
to change by you.

If not then I will erase the wiki (it is only start page now anyway).