All of the onlick events happen first, then the default behavior of the HTML. Think of it this way... if you were listening for a keypress in a textbox rather than a mouse click. The onkeydown, onkeyup, and onkeypress events are all processed before the character typed is added to the textbox.

Does that make sense?

Nathan

kkus wrote:
In example of events chapter, for an outer element1 and inner element2 when I
click on element2 there is an event bubbling from element2 to element1.
So I don't understand why in our case if I click on a.href (inner element)
tr.onclick (outer element) will be processed first in IE6.

GojiraDeMonstah wrote:
I found this online book excerpt helpful and interesting:
http://www.quirksmode.org/js/contents.html , especially the events
chapter.

Jason
<http://www.quirksmode.org/js/events_advanced.html>


On 12/28/06, kkus <[EMAIL PROTECTED]> wrote:
I don't think <tr> is processed first.   will be processed first and it
will
trigger onclick event when href link is clicked. Since IE6 only supports
event bubbling, it will get its ancestor's onclick event. Ancestor's
onclick
is then processed like opening a new link as JavaScript code instructs,
then
return false which will prevent its descendant's default action from
occurring - in this case   to open its link.

If you really want to prevent an event from bubbling, you has to assign
cancelBubble=true to that event. Return false can only prevent event's
default action from happening.


melinate wrote:
Basically you are clicking the row (the TR element) and the anchor (A)
at the same time.. well not really at the same time the TR is getting
processed first, but it only takes one physical click of the mouse to
trigger both events.  By adding the "return false" you are telling the
browser to stop processing the additional events.  So basically the
method below does the following when someone clicks anywhere on the TR:

    get the first cell of the row
    get the link out of the first cell in the row
    navigate the browser to that link
    set the cursor to "wait" until the new page loads
    stop processing any additional event listeners triggered by the
click
This is an over simplification of what event bubbling is, but I think
you get the idea.


Nathan

kkus wrote:
It works after I added return false at the bottom of event method(see
below).
But curiously, how come can this row event be ignored if I clicked on
an
anchor tag, and "return false" doesn't prevent row event's default
action
from firing if clicking in a row? Is anchor tag event "overriding" row
event?

rows[i].onclick = function() {
            var cell = this.getElementsByTagName("td")[0];
            var link = cell.getElementsByTagName("a")[0];
            location.href = link.getAttribute("href");
            this.style.cursor="wait";
            return false;
        }


melinate wrote:

This whole thing just started making a lot of sense...  Now that it
is
isolated to the being a combination of the anchor tag and the JS
onclick
method.

If adding "return false" to the bottom of that JS method works, could
you add a bug report in JIRA about it.

Nathan


Sanjiv Jivan wrote:

Like I said in my previous mail, the onclick handler should be
returning 'false' in order to prevent both, the onclick handler and
the ahref being called.

I think this js function makes the entire row "act" like a clickable
URL. It should be returning 'false' though.



On 12/27/06, *kkus* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:


    The problem lies in highlightTableRows() in global.js. If I
    commented out
    following code in that method, there is only one request fired.
Is
    that a
    bug? Or why do we need this piece of code?

    rows[i].onclick = function() {
                var cell = this.getElementsByTagName("td")[0];
                var link = cell.getElementsByTagName("a")[0];
                location.href = link.getAttribute("href");
                 this.style.cursor="wait";
            }


    kkus wrote:
    >
    > By disabling javascript in IE6, I can see only one GET
request.
But
    > haven't figured out where the responsible javascript is.
    >
    >
    > Sanjiv Jivan wrote:
    >>
    >> Try directly entering the url in the browser and see if
you're
    still
    >> getting
    >> two requests. That way you can see if displaytag has anything
    to do with
    >> it.
    >> Enter the url that disaplytag is issuing (is it calling
    /user/a.html or
    >> /editUser.html?)
    >>
    >>
    >> On 12/26/06, kkus < [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> wrote:
    >>>
    >>>
    >>> I commented out both rewriteFilter and exportFilter in
    web.xml, but I
    >>> still
    >>> get the same two requests. Not sure why it only happens in
    editUser
    >>> action
    >>> with displaytag. BTW, why do we need urlwriter.xml file as
below?
    >>>
    >>> <urlrewrite>
    >>>     <rule>
    >>>         <from>^/user/(.*).html$</from>
    >>>         <to type="forward">/editUser.html\?username=$1</to>
    >>>     </rule>
    >>> </urlrewrite>
    >>>
    >>>
    >>> Sanjiv Jivan wrote:
    >>> >
    >>> > I'm thinking that the app is doing a redirect, probably
    because of one
    >>> of
    >>> > the servlet filters.
    >>> >
    >>> > On 12/26/06, kkus < [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> wrote:
    >>> >>
    >>> >>
    >>> >> After I used Fiddler, I can still see two requests issued
    when code
    >>> >> stopped
    >>> >> in FrameworkSevlet breakpoint. Following are two request
    headers from
    >>> >> Fiddler. The only difference is second one has a referer,
    and I still
    >>> >> can't
    >>> >> tell the source sending these two requests. Any idea?
    >>> >>
    >>> >> 1.
    >>> >> GET /appfuse/editUser.html?username=a&from=list HTTP/1.1
    >>> >> Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg,
    >>> >> application/x-shockwave-flash, application/vnd.ms-excel,
    >>> >> application/vnd.ms-powerpoint, application/msword, */*
    >>> >> Accept-Language: en-us
    >>> >> Accept-Encoding: gzip, deflate
    >>> >> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
    5.1; SV1;
    >>> .NET
    >>> >> CLR
    >>> >> 1.1.4322)
    >>> >> Host: localhost:8008
    >>> >> Proxy-Connection: Keep-Alive
    >>> >> Cookie: username=a;
    JSESSIONID=F9764F1BEEE98A5B8503FD27835A9EB7;
    >>> >>
    >>> >>
    >>>


ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=YToxMTY4Mzc5MDEzMTIyOmYyZTQ1MjY0YWEzNTgxZTg5ZjFjYTkxMjY3OWYyNGNj
    >>> >>
    >>> >> 2.
    >>> >> GET /appfuse/editUser.html?username=a&from=list HTTP/1.1
    >>> >> Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg,
    >>> >> application/x-shockwave-flash, application/vnd.ms-excel,
    >>> >> application/vnd.ms-powerpoint, application/msword, */*
    >>> >> Referer:
    >>> >>
    >>> >>
    >>>


http://localhost:8008/appfuse/users.html;jsessionid=B3B335082176A4F176F0A6BD328F57F4
    >>> >> Accept-Language: en-us
    >>> >> Accept-Encoding: gzip, deflate
    >>> >> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
    5.1; SV1;
    >>> .NET
    >>> >> CLR
    >>> >> 1.1.4322)
    >>> >> Host: localhost:8008
    >>> >> Proxy-Connection: Keep-Alive
    >>> >> Cookie: username=a;
    JSESSIONID=F9764F1BEEE98A5B8503FD27835A9EB7;
    >>> >>
    >>> >>
    >>>


ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=YToxMTY4Mzc5MDEzMTIyOmYyZTQ1MjY0YWEzNTgxZTg5ZjFjYTkxMjY3OWYyNGNj
    >>> >>
    >>> >>
    >>> >> Sanjiv Jivan wrote:
    >>> >> >
    >>> >> > All decent debuggers have a Call Stack / Frame view
which
    allows
    >>> you
    >>> to
    >>> >> > trace the sequence of methods that led to the current
    call being
    >>> made.
    >>> >> So
    >>> >> > by
    >>> >> > examining the higher order call stacks, you should be
able
to
    >>> figure
    >>> >> out
    >>> >> > why
    >>> >> > the calls are being made twice. Which IDE / debugger
are
    you using?
    >>> >> >
    >>> >> > Is the request being made by a javascript onclick call
    which does
    >>> not
    >>> >> > return
    >>> >> > false causing the request to be submitted twice? Try
running
    >>> Fiddler
    >>> to
    >>> >> > confirm that the request is being issued only once.
Once
    you've
    >>> ruled
    >>> >> that
    >>> >> > out, examine the call stack to narrow down the issue.
    >>> >> >
    >>> >> > Sanjiv
    >>> >> >
    >>> >> > On 12/22/06, kkus <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> wrote:
    >>> >> >>
    >>> >> >>
    >>> >> >> When breakpoint was hit, I checked request field and
    both have the
    >>> >> same
    >>> >> >> session id and seems identical. What specific object
or
    variable
    >>> do
    >>> >> you
    >>> >> >> want
    >>> >> >> me to check?
    >>> >> >>
    >>> >> >>
    >>> >> >> Sanjiv Jivan wrote:
    >>> >> >> >
    >>> >> >> > Examine the call stack in your debugger when the
    breakpoints are
    >>> >> hit.
    >>> >> >> >
    >>> >> >> > On 12/22/06, kkus <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> wrote:
    >>> >> >> >>
    >>> >> >> >>
    >>> >> >> >> In 1.9.4 Spring MVC, I put a breakpoint at doGet()
of
    >>> >> >> >> FrameworkServlet.java.
    >>> >> >> >> Then in Administration - View Users page I clicked
a
    link for a
    >>> >> user
    >>> >> >> then
    >>> >> >> >> there are two threads stopping at the same
    breakpoint. It seems
    >>> >> only
    >>> >> >> >> happen
    >>> >> >> >> in displaytag or only for Get request. How can I
    debug the root
    >>> >> cause
    >>> >> >> for
    >>> >> >> >> sending same request twice? Thanks!
    >>> >> >> >> --
    >>> >> >> >> View this message in context:
    >>> >> >> >>
    >>> >> >>
    >>> >>
    >>>


http://www.nabble.com/tough-question%3A-doGet-request-fired-twice-in-displaytag-tf2872720s2369.html#a8029262
<
http://www.nabble.com/tough-question%3A-doGet-request-fired-twice-in-displaytag-tf2872720s2369.html#a8029262
    >>> >> >> >> Sent from the AppFuse - User mailing list archive
at
    >>> Nabble.com <http://Nabble.com>.
    >>> >> >> >>
    >>> >> >> >>
    >>> >>


---------------------------------------------------------------------
    >>> >> >> >> To unsubscribe, e-mail:
    [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >>> >> >> >> For additional commands, e-mail:
    >>> [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >>> >> >> >>
    >>> >> >> >>
    >>> >> >> >
    >>> >> >> >
    >>> >> >>
    >>> >> >> --
    >>> >> >> View this message in context:
    >>> >> >>
    >>> >>
    >>>


http://www.nabble.com/tough-question%3A-doGet-request-fired-twice-in-displaytag-tf2872720s2369.html#a8029490
<
http://www.nabble.com/tough-question%3A-doGet-request-fired-twice-in-displaytag-tf2872720s2369.html#a8029490
    >>> >> >> Sent from the AppFuse - User mailing list archive at
    Nabble.com <http://Nabble.com>.
    >>> >> >>
    >>> >> >>
    >>>


---------------------------------------------------------------------
    >>> >> >> To unsubscribe, e-mail:
    [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >>> >> >> For additional commands, e-mail:
    [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >>> >> >>
    >>> >> >>
    >>> >> >
    >>> >> >
    >>> >>
    >>> >> --
    >>> >> View this message in context:
    >>> >>
    >>>


http://www.nabble.com/tough-question%3A-doGet-request-fired-twice-in-displaytag-tf2872720s2369.html#a8057366
    >>> >> Sent from the AppFuse - User mailing list archive at
    Nabble.com <http://Nabble.com>.
    >>> >>
    >>> >>


---------------------------------------------------------------------
    >>> >> To unsubscribe, e-mail:
    [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >>> >> For additional commands, e-mail:
    [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >>> >>
    >>> >>
    >>> >
    >>> >
    >>>
    >>> --
    >>> View this message in context:
    >>>


http://www.nabble.com/tough-question%3A-doGet-request-fired-twice-in-displaytag-tf2872720s2369.html#a8059518
    >>> Sent from the AppFuse - User mailing list archive at
    Nabble.com <http://Nabble.com> .
    >>>
    >>>


---------------------------------------------------------------------
    >>> To unsubscribe, e-mail:
[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >>> For additional commands, e-mail:
    [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >>>
    >>>
    >>
    >>
    >
    >

    --
    View this message in context:


http://www.nabble.com/tough-question%3A-doGet-request-fired-twice-in-displaytag-tf2872720s2369.html#a8064836
<
http://www.nabble.com/tough-question%3A-doGet-request-fired-twice-in-displaytag-tf2872720s2369.html#a8064836
    Sent from the AppFuse - User mailing list archive at Nabble.com
    <http://Nabble.com>.



---------------------------------------------------------------------
    To unsubscribe, e-mail: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    For additional commands, e-mail: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
View this message in context:
http://www.nabble.com/tough-question%3A-doGet-request-fired-twice-in-displaytag-tf2872720s2369.html#a8080566
Sent from the AppFuse - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to