search

aolarchive / jquery-liveupdate

Other
8 stars 2 forks source link

Polling sometimes incorrectly starts from Sonar event #34

Open jeremyjannotta opened 11 years ago

jeremyjannotta commented 11 years ago

In liveupdateApi, polling can resume from a Sonar 'scrollin' event, even if options.state.alive is false. (https://github.com/aol/jquery-liveupdate/blob/master/src/liveupdateapi.js#L251)

However, if alive is set to false by the initial config option, and the widget is visible in the screen initially, polling starts right away, which seems like incorrect, or at least unintended, behavior.

Perhaps there's logic to allow for this, or maybe a new config option is required.

neagle commented 11 years ago

Any chance you've already fixed this? I'm having some trouble reproducing the bug.

jeremyjannotta commented 11 years ago

Looks like it still exists, here's how I reproduced it: 1) Load sonar plugin in simple_widget page -- http://o.aolcdn.com/os/aol/jquery.sonar.min.js 2) Set alive option to false

When you load this example page, you'll note that it's still polling for updates, but should be disabled (pause button hidden).

What I think is happening is: 1) api plugin loads, with alive=false 2) immediately picks up sonar's 'scrollin' event, because it's already visible, and fires the live() function 3) live() says: if !alive, then fetch, and set alive to true (https://github.com/aol/jquery-liveupdate/blob/master/src/liveupdateapi.js#L291) 4) viola, polling starts

Seems that maybe the alive option may be overloaded, because it's used to both set the global state of the widget, and also represent the current state of the widget. So, maybe there's other logic to fix this, or we could swap state.options.alive -> state.options.pollEnabled , or anything else, then update logic to properly use both.