My best guess is that IE is trying to GET the contents pointed to by the link, and at the same time process your onClick event, and the two are conflicting. That is just a guess, but I have indeed seem similar behavior when using a link. One thing you can do is to not make it a link at all, instead just have a <div>, and maybe update the cursor style, so something like this:
<div onMouseOver="this.style.cursor='pointer';" onMouseOut="this.style.cursor='normal';" onClick="javascript:getNext();">Next</div> Otherwise, the other thing to try is to add "return false;" to the end of your href, so: <a href="javascript:void(0);return false;" onClick="javascript:getNext();">Next </a> I'm not 100% sure, but I think that will cause the transition to void(0) to not happen. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Wed, April 5, 2006 3:56 pm, zahid mohammed said: > Though this problem was resolved long time back, I was just wondering what > the actual problem was. > > The problem was resolved just by replacing > > > <a href="javascript:void(0)" onClick="javascript:getNext();">Next </a> > > with > > <input type="button" value="Next" onClick="javascript:getNext();"> > > Using the anchor tag, the HTTPWatch showed that the HTTP operation was > aborted by IE, where as by using the button it went on the next page and > showed the right set of elements. > > Can anyone please tell me what the problem was with the anchor tag and why > did IE abort the operation. > > Thanks for all the help! > > > > > > On 2/18/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >> Aborted can happen when a proxy is involved, which has been suggested >> before as the source of your troubles. I think it would be in your best >> interest to purchase HTTPWatch to see the full details, or else find a >> free alternative... some options: >> >> http://www.siliconwold.com/interceptor/interceptor_home.htm >> http://www.blunck.info/iehttpheaders.html >> >> http://www.fileedge.com/Cat/Network-Internet/Browsers-Tools/MMD-HttpHead.html >> >> None of them seem as good as HTTPWatch, but the price is right :) >> >> Frank >> >> zahid mohammed wrote: >> > Hi Dave, >> > I have used the basic edition of HttpWatch and found these results >> after >> > clicking "next" >> > >> > Started Time size method Result Type >> > 00:01:58.512 0.004 * POST Aborted * >> > URL >> > >> > >> http://localhost:8080/WITRApplication/GetOtherSet.do?nextposition=10&rand=93395784 >> > 00:02:14.239 0.003 * POST Aborted * >> > >> http://localhost:8080/WITRApplication/GetOtherSet.do?nextposition=10&rand=53881851 >> > >> > Since this is a basic edition of HttpWatch I am unable to see the >> headers, >> > cookies, cache etc. Does anyone know what "Aborted" means in the >> result >> and >> > when does it show that? >> > >> > PLEASE HELP!!! >> > Thanks. >> > >> > On 2/17/06, Dave Newton <[EMAIL PROTECTED]> wrote: >> >> zahid mohammed wrote: >> >>> If something was fundamentally wrong then why would it work in >> >> "FIREFOX". >> >> Perhaps because Firefox is less fundamentally broken than IE? >> >>> And moreover these two printlns are giving the same result in >> Firefox >> >> but >> >>> not in IE i.e after clicking next these are printing the next page's >> >> first >> >>> element. I am in the process of using HTTPWatch. I'll let u guys >> know >> >> the >> >>> result later. >> >>> >> >> What do you mean by "first element?" Those printlns are half-way >> through >> >> the source you posted; there is quite a bit of HTML before them. >> >> >> >> I should rephrase my belief: obviously there is different behavior >> under >> >> IE, but I'm quite skeptical that it's an issue with caching insofar >> as >> >> the headers you are sending are correct and you are sending a >> >> cache-busting unique URL parameter. We use both techniques (and have >> for >> >> a long time) with zero issues across "all" browsers. >> >> >> >> I still believe that there is either more going on under IE than you >> >> suspect with regards to a proxy, a cache, something, somewhere in the >> >> request chain. >> >> >> >> I would recommend you test w/ a different version of IE6 and see if >> the >> >> problem goes away; if it does then obviously that drop of IE is >> >> significantly broken. I would also examine your entire request >> >> processing chain, and create a standalone test case without all the >> >> extra stuff to make it easier to track down the problem to see if it >> >> really _is_ an IE-specific caching bug or if it's somewhere else in >> the >> >> chain. >> >> >> >> Dave >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
