search

olbers / iui

Automatically exported from code.google.com/p/iui
MIT License
0 stars 0 forks source link

Multiple list or backButton touches/clicks causes unexpected behavior #191

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
i have a list with many a links.

now i touch one link - the spinning process icon appear

now i touch a secand link - here also the spinning process icon appear
and i have 2 spinning icons

and now the first page is displayed shortly and after this the second
page is show.

the problem now:

the back button in not working properly anymore. i can touch it and it
goes back but i get a slide animation but resulting in empty white
pages. i think the back button is not synchron to the pages.

i see two workareas:
- fix the history thing that this is synchron in this case

or more generaly:
a) avoid in a list a second touch to an other list item
or
b) if i click a second link then cancel the first link processing and
do only the second link processing <--- i think that is what the user
is expected

Original issue reported on code.google.com by tonygilb...@gmail.com on 5 Nov 2009 at 10:31

GoogleCodeExporter commented 9 years ago 
I am going to try to fix this one tonight.  Anyone out there with any working 
patches?

Original comment by msgilli...@gmail.com on 10 Mar 2010 at 6:00

GoogleCodeExporter commented 9 years ago 
Not sure I could implement, but option b sounds like the way to go. I'm thinking
something in iui.js click event handler for links, or ajax functions to nuke 
first
request its not already done. Perhaps some sort of callback maybe? Just a 
thought but
call back is something I don't understand yet. Anyone else?

Original comment by vichuds...@gmail.com on 10 Mar 2010 at 6:25

GoogleCodeExporter commented 9 years ago 
I'm actually leaning towards taking only the first click/touch and ignoring 
subsequent ones.  Cancelling would be 
tricky, I think...

I have some code which ignores subsequent touches/clicks on the back button and 
it works pretty well.

This issue affects both forward and backward page transitions with and without 
Ajax.  I'm changing the title of 
this issue to be more descriptive and general.

Original comment by msgilli...@gmail.com on 10 Mar 2010 at 6:29

GoogleCodeExporter commented 9 years ago

Original comment by msgilli...@gmail.com on 10 Mar 2010 at 6:37

GoogleCodeExporter commented 9 years ago 
Well, "tonight" was optimistic.  It looks like iUI could use a little 
refactoring to make this easier.  I'm going to try a 
brute force locking approach on my iUI-based app.  With what I learn from that 
process, I'll try to fix iUI.  It'll be 
a few days before anything shows up in Hg.  I'll definitely need 
help/feedback/testing on this one.

Original comment by msgilli...@gmail.com on 10 Mar 2010 at 6:05

GoogleCodeExporter commented 9 years ago 
I have an idea Sean. It may be crazy and not work at all, but I'm gonna throw 
it out
there. What about an event listener on the body for clicks that sets a Boolean 
flag
that gets reset after a time out, and then have the click handler for links in 
iui.js
check the status of this flag before doing the usual link options? All link 
handling
could be disabled for x amount of time after link click to prevent accidental 
clicks.
Thoughts?

Original comment by vichuds...@gmail.com on 10 Mar 2010 at 8:36

GoogleCodeExporter commented 9 years ago 
@Vic You're barking up the right tree.  It gets a little more complicated 
because transitions can be started 
without a click.  This can happen in forms and if a webap calls one of the 
public iUI functions directly.  I'm 
barking up the same tree.

Original comment by msgilli...@gmail.com on 10 Mar 2010 at 8:41

GoogleCodeExporter commented 9 years ago 
Here's a really quickly hacked together fix that seems to work:
http://code.google.com/p/iui/source/detail?r=6d775eba42500dbaf70192ab32290a01112
51789

Feedback is very welcome!  Does anyone have a better solution?

Original comment by msgilli...@gmail.com on 11 Mar 2010 at 12:13

GoogleCodeExporter commented 9 years ago 
BTW, I noticed that the  (page == currentPage) situation in iui.showPage is the 
most common 'not behaving as 
expected" case.  That's why I added a check there.

Original comment by msgilli...@gmail.com on 11 Mar 2010 at 12:18

GoogleCodeExporter commented 9 years ago 
Congrats Sean. Looks like you got it. I was checking out the diff. I like the 
way it
shows side by side compare with changes highlighted. Is that a benefit of 
mercurial
and does it do it auto? I definitely need to learn that, especially since I 
just made
a new extension and uploaded to related issue#47, out of lack of anywhere else 
to put
it. I should have a new update for it by tomorrow or Friday at the latest. A 
clone
would make that much easier to handle, I think. I'll see if I can get a grip on
mercurial before the update. Crunched for time though, spring break half over 
already
and life will crash in. Any way, you should check out extension on issue#47, 
it's
pretty cool. And I put new post on #216 by the way.

:)
Vic

Original comment by vichuds...@gmail.com on 11 Mar 2010 at 2:06

GoogleCodeExporter commented 9 years ago 
So, the iui.busy flag has been in iUI since the iui-0.40-alpha1 and seems to 
fix these issues.  I'm going to close this bug.  If there is a case where the 
iui.busy flag is not work correctly, please open a new bug and provide detailed 
information about the scenario.

Original comment by msgilli...@gmail.com on 9 Jan 2012 at 6:43