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

M

Mark Anderson

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
 
L

Lasse Reichstein Nielsen

Mark Anderson said:
<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
 
M

Mark Anderson

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
 
L

Lasse Reichstein Nielsen

Mark Anderson said:
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
 
M

Mark Anderson

Lasse,

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

Regards

Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,813
Latest member
lawrwtwinkle111

Latest Threads

Top