By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,101 Members | 1,463 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,101 IT Pros & Developers. It's quick & easy.

Problems with location.href, query URL and IE(Mac) & Safari

P: n/a
Sorry if this is a rookie mistake... I've been through all the FAQs and the
books I have but I can't see the mistake so I guess it's something simple
<g> - I'm an occasional JS user.

I've got some code (in an external JS file) attached to a number of links
off a query result page. The code it checks if there are any ticked items on
the page and adds them to a lightbox (cart) before going the next called
result page. The idea is to stop the user taking any link off the page and
inadvertently remembering to add their selections to the lightbox.

The initial call is from a link, either to another result page in the same
query 'set' or to various static pages or predefined queries. The example
below is a call to load the lightbox (code my wrap):
<a href="#"
onclick="goWhere('LIGHTBOX','../scripts/portweb.dll?show&catalog=test&templa
te=lightbox','ADD',document.resultAdd);">Show Lightbox</a>

function goWhere(linkName,theURL,task,theForm) takes parameters for the type
of destination, the query string, the action (Add or Delete) for the
lightbox and the calling form. If there are no checked items (for adding to
the lightbox) on the page, the call falls through the various functions
passing back 'theURL' which is than set as the page is called as (code
excerpt):

var target = constructURL(linkName, theURL);
document.location.href = target;

Note - the query strings being used are otherwise fine and not, I believe,
the cause of the problem.

So, the code executes in a function in an external file. It words fine in
IE6 Win but in IE5 Mac and Safari 1 Mac it stops. It seems the location.href
is not being executed correctly and this is where the code breaks. It even
breaks if, as a test, I use
document.location.href = 'index.htm';
to point to a static page. The Mac browsers just don't seem to like
location.href.

Any pointers gratefully received,

Regards

Mark
Jul 20 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"Mark Anderson" <ma**@notmeyeardley.demon.co.uk> writes:
<a href="#"
onclick="goWhere('LIGHTBOX','../scripts/portweb.dll?show&catalog=test&templa
te=lightbox','ADD',document.resultAdd);">Show Lightbox</a>
Remember to return false form your onclick handler. Some browsers will
reload the page otherwise.

You should escape your "&"'s in attributes, by turning them into
"&amp;".
(code excerpt):

var target = constructURL(linkName, theURL);
document.location.href = target;


Try
location.href = target;
The location object is usually a property of the window, not the
document.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #2

P: n/a
Lasse,

Thanks. both fixes were right on the money.

The use of return false with onClick calls in the older/more picky browsers
is one of the least well documented. Oddly it is one think the otherwise
good O'Reilly JS books don't bother to cover.

If there are any well explained (i.e. little assumed knowledge) examples of
correct use of 'return false' within <a> link events, I'd be very happy if
you or anyone else could note the URLs

Regards

Mark
Jul 20 '05 #3

P: n/a
"Mark Anderson" <ma**@notmeyeardley.demon.co.uk> writes:
If there are any well explained (i.e. little assumed knowledge) examples of
correct use of 'return false' within <a> link events, I'd be very happy if
you or anyone else could note the URLs


I don't have an URL available, but the rule is simple:

If you don't return false, the link is followed (as if there was no
onclick handler). If you do return false, the click event is canceled,
and the link is not followed.

You should always return false if you don't mean to follow the link.

What you ran into here was a combination of this and the href="#" link.
It points to the current page, at a non-existing identifier (just as
href="#foo" would point to the element with id="foo"). Since it is the
current page, the browser don't *need* to load it, but some do anyway
(which could probably be correct for dynamic pages). Internet Explorer
doesn't change anything when following href="#", which is why you
could get away with not returning the appropriate false.

Generally, all events are cancelled by returning false from the
handler (if the event can be canceled at all, obviously).

The more modern way of attaching event handlers to elements is the W3C
DOM 2. There, you don't return false. Instead you call the method
preventDefault on the event object. All browsers still support the old
way, and probably will for quite a while, and IE doesn't understand
W3C DOM 2 Events at all.

Returning false is mentioned in some of the FAQ entries:
<URL:http://jibbering.com/faq/#FAQ4_24>
<URL:http://jibbering.com/faq/#FAQ4_27>

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #4

P: n/a
Lasse,

Thanks. My problem in solving the last was in large part through wrongly
diagnosing the location.href call as the cause.

Regards

Mark
Jul 20 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.