done button moves around when having a resized window

[GoogleCodeExporter]

What steps will reproduce the problem?
1. resize the main window
2. click the 'i' to change some filters, etc
3. click on the done button
4. the button moves to reflect the main window size/position

What is the expected output? What do you see instead?

the 'done' shouldn't move.

What version of Milk the Cow are you using? On which version of OS X?

0.5.0 on 10.5.8

Please provide any additional information below.

Original issue reported on code.google.com by jin.y...@gmail.com on 10 Dec 2009 at 10:16

[GoogleCodeExporter]

just realized the i also moves (you'll have to catch it before it goes into the
animation)

Original comment by jin.y...@gmail.com on 10 Dec 2009 at 10:17

[GoogleCodeExporter]

here's a fix...

in the showFront(event) method in the milkthecow.js file, swap L154 and L155:

   document.getElementById("back").style.display="none";
   document.getElementById("front").style.display="block";

dunno the i thing.

Original comment by jin.y...@gmail.com on 10 Dec 2009 at 10:25

[GoogleCodeExporter]

scratch my last comment... doesn't work.  :/

Original comment by jin.y...@gmail.com on 10 Dec 2009 at 10:28

[GoogleCodeExporter]

it seems it's b/c it takes quite a noticeable amount of time before things are
updated that this issue arises.  the lag between flippping (getting rtm data) 
appears
to be a few seconds for me.  that's pretty unacceptable.  can there be anything 
done
to change to move away from async calls?

Original comment by jin.y...@gmail.com on 10 Dec 2009 at 10:42

[GoogleCodeExporter]

This issue was closed by revision b97c3d1b82.

Original comment by hong.rich on 11 Dec 2009 at 12:01

• Changed state: Fixed

[GoogleCodeExporter]

Try the latest revision I just checked in. If this works for you, I will 
release it
as 0.5.1

Another problem that I discovered while testing is that Milk the Cow doesn't 
handle
error conditions at all. If the network goes down or Remember the Milk service
stopped responding, the widget could easily hang. But this a topic for a 
different
issue (issue 35).

Original comment by hong.rich on 11 Dec 2009 at 12:06

[GoogleCodeExporter]

the way to unblock is to fail on async after a timeout.  alternatively, you can 
go
sync w/ x number of retries until failure.

Original comment by jin.y...@gmail.com on 11 Dec 2009 at 7:51

[GoogleCodeExporter]

I just tried adding a simple 5 second timeout, but it seemed to have made it 
worse.
Let me know if you can get it to work.

Original comment by hong.rich on 11 Dec 2009 at 9:42

[GoogleCodeExporter]

if you're talking about the rtm call, i'd suggest asking the rtm devs what their
service level agreement wrt the tp99 (99th worst percentile timing) would be.  
from
there, code around that.

Original comment by jin.y...@gmail.com on 11 Dec 2009 at 10:22

[GoogleCodeExporter]

Timing would also depend on the user's connection. And either way, I want this 
to be
more robust than just a simple timeout, possibly retries if a request timed out.
There is also a case where rtm calls would return an error status page instead 
of a
json response. I saw this happened once but didn't have code to handle this 
case yet.

Original comment by hong.rich on 11 Dec 2009 at 10:48