Safari 1.3 - 2.0.3 link events

0 views
Skip to first unread message

Juergen Schreck

unread,
Dec 4, 2006, 7:58:03 PM12/4/06
to MochiKit
Ok - perhaps I've tried a little too long and just can't see it. But
I have a problem with a client using Safari 1.3 thru 2.0.3 reporting
a problem with my javascript.

I hope someone knows about this issue and can turn the lights on for
me as to how to work around this problem.

Consider the following code in <head>

<script type="text/javascript">
connect(window, 'onload', function (e) {
app.home(e);
var elems=$('header').getElementsByTagName('a');
connect(elems[0], 'onclick', app.home);
var elems=getElementsByTagAndClassName('a','menu_item');
for (idx in elems) {
connect(elems[idx], 'onclick', app.menu_action);
}
});
</script>

And then somewhere in the markup:

<li><a name="mediarelations" class="menu_item" href="#"></a></li>
<li><a name="graphicdesign" class="menu_item"
href="graphicdesign.html"></a></li>

The difference in the two links is the href. On the aforementioned
Safari versions it seems like the href always gets executed BEFORE
the onclick event fires, unless I put a # in there. So the first link
above will work, the second won't - meaning it'll try to load
graphicdesign.html and app.menu_action never get's a chance to
execute. I do return false from app.menu_action, which prevents the
execution of the href link as expected.

What to do?

Thanks,
Juergen

Bob Ippolito

unread,
Dec 4, 2006, 9:04:00 PM12/4/06
to Juergen Schreck, MochiKit

returning false is not how that works. You're supposed to call
e.stop() (or stopPropagation or preventDefault depending on if you
want just one of them).

-bob

Juergen Schreck

unread,
Dec 4, 2006, 9:58:38 PM12/4/06
to MochiKit

On Dec 4, 2006, at 8:04 PM, Bob Ippolito wrote:

> returning false is not how that works. You're supposed to call
> e.stop() (or stopPropagation or preventDefault depending on if you
> want just one of them).

Bob, that's right. And I am doing that. Here's an excerpt of
app.menu_action:

menu_action: function(e) {
e.stop();
el=e.src();
el.blur();

// more stuff ....

return false;
}


So I'm doing all those things, but still at least confirmed in Safari
1.3 the link is executed before the onclick event.

Workarounds I've come up with so far:

- rewrite href attribute to "#" when making connecting the signal
- forget signal and put "onclick" attribute in the markup (silly
enough, but makes it work)

Something doesn't smell right. But what is it?

Juergen

Bob Ippolito

unread,
Dec 4, 2006, 10:48:38 PM12/4/06
to Juergen Schreck, MochiKit
The next step is to produce a full example with HTML and JavaScript so
that someone else can reproduce the issue and diagnose it.

-bob

On 12/5/06, Juergen Schreck <juergen...@innernine.com> wrote:
>
>

Juergen Schreck

unread,
Dec 4, 2006, 11:15:08 PM12/4/06
to MochiKit
Ok, this should do. Pretty straightforward stuff.

Doesn't work in Safari 1.3:
http://www.bwpr.com/new.html

Works in Safari 1.3 by rewriting href attribute
http://www.bwpr.com/new2.html

Thanks in advance for any insight,
Juergen

Bob Ippolito

unread,
Dec 4, 2006, 11:38:11 PM12/4/06
to Juergen Schreck, MochiKit
Since this isn't a reduced example, what exactly do you mean by
"doesn't work"? What are the exact steps to reproduce?

In other words, what should be clicked, what should happen when it's
clicked, and what currently happens in Safari 1.3?

Juergen Schreck

unread,
Dec 5, 2006, 12:07:57 AM12/5/06
to Bob Ippolito, MochiKit
Ok, sorry about that.

On the main page, click 'Community Relations' or 'Media Relations'.

This click should trigger the next animation overriding what's in
href attribute. Menu images drop out and subpage slides down.

On the http://www.bwpr.com/new.html page, this doesn't work in Safari
1.3. Instead of running the animation (executing the 'connected'
onclick signal, it actually tries to follow the href (resulting in a
404 error). This page work as expected however in Safari 2.0.4, FF
and IE6+.

On the http://www.bwpr.com/new2.html page, I worked around the Safari
1.3 problem by rewriting the href attribute. Still work in all the
others too.

Let me know if I can provide more info.

And thanks for your patience.

Regards,
Juergen

Juergen Schreck

unread,
Dec 5, 2006, 12:55:28 AM12/5/06
to MochiKit
Found some more info here.

http://www.codingforums.com/archive/index.php?t-30983.html

Given the date of those posts, and the fact that one of my clients
was running 2.0.3 (the latest official version being 2.0.4) it
probably was only recently fixed.

I don't know if this is some MochiKit can/should work around.

Regards,
Juergen

Beau Hartshorne

unread,
Dec 5, 2006, 2:40:15 AM12/5/06
to MochiKit, Juergen Schreck
On 4-Dec-06, at 9:55 PM, Juergen Schreck wrote:

> Found some more info here.
>
> http://www.codingforums.com/archive/index.php?t-30983.html
>
> Given the date of those posts, and the fact that one of my clients
> was running 2.0.3 (the latest official version being 2.0.4) it
> probably was only recently fixed.
>
> I don't know if this is some MochiKit can/should work around.

Here's a reduced test you can try:

<a id="one" href="#one" onclick="return false;">one</a>
<a id="two" href="#two">two</a>

<script type="text/javascript" charset="utf-8">
connect('one', 'onclick', function(e) {
e.stop();
alert('one');
});

connect('two', 'onclick', function(e) {
e.stop();
alert('two');
});
</script>

You don't need to return false from the event handlers you call with
connect, that doesn't do anything. Adding onclick="return false;" to
the <a> tags shouldn't cause any problems.

Beau

Juergen Schreck

unread,
Dec 5, 2006, 8:19:23 AM12/5/06
to MochiKit

On Dec 5, 2006, at 1:40 AM, Beau Hartshorne wrote:

> You don't need to return false from the event handlers you call
> with connect, that doesn't do anything. Adding onclick="return
> false;" to the <a> tags shouldn't cause any problems.

I realize that now. I was just still doing it [in addition to stop()]
because that's what I was used to doing.

But are you saying that in addition to connecting the signal, I can
add an onclick attribute? I though I read somewhere [in the MK doco]
that that can cause unpredictable problems. But now I can't find that
text...

Regards,
Juergen

Juergen Schreck

unread,
Dec 5, 2006, 8:37:21 AM12/5/06
to MochiKit
Ok, I've done some more testing with the simplified script:

<a id="one" href="#one">one</a>


<a id="two" href="#two">two</a>

<script type="text/javascript" charset="utf-8">

$('one').onclick=function(){ return false; };

connect('one', 'onclick', function(e) {
e.stop();
alert('one');
});

connect('two', 'onclick', function(e) {
e.stop();
alert('two');
});
</script>


Basically, rather than adding the onlick attribute in the markup, I
added it in code. And it works properly with Safari 1.3+ and still
works with others. The question now becomes if this is some MochiKit
could/should handle transparently? There's a lot of pre-2.0.4
Safari's out there...

I guess it would be an exception in connect for Safari if the source-
element is an <a> and the event is 'onclick'.

Juergen

On Dec 5, 2006, at 1:40 AM, Beau Hartshorne wrote:

Beau Hartshorne

unread,
Dec 5, 2006, 1:49:23 PM12/5/06
to MochiKit, Juergen Schreck
Doing a "return false;" shouldn't hurt anything. Not everyone wants
to stop onclick events on <a> tags, so it doesn't make sense to add
that to Signal. I've added a note about this bug to the docs:
http://trac.mochikit.com/changeset/1230

Thanks,
Beau

Reply all
Reply to author
Forward
0 new messages