Nav links are not always clickable.

open-learning-exchange / BeLL-Apps

This is the third iteration of the BeLL software. It's a Backbone.js app that caches itself in the browser that is backed by CouchDB when a server is available and PouchDB in the browser when a server is not available. Initial support for PDFs is currently implemented, support for Videos and single HTML5 Apps coming next. Tracking bugs and new features in the Wiki at the moment.

12 stars 39 forks source link

Nav links are not always clickable. #585

Open waryhermit opened 7 years ago

waryhermit commented 7 years ago

Steps to reproduce Using Firefox 50:

Go to MyHome in the BeLL app.
Click on MyHome again, then carefully slide your cursor over to another link, such as meetups.
Notice how it does not turn green and does nothing the first time you click.
Note: it may take multiple attempts for the bug to appear.

lmmrssa commented 7 years ago

It seems to be the case of someone clicks the link then it takes sometime to reload and there might have been loading icon missing causing confusion. When someone clicks any link site becomes irresponsive for few time.

waryhermit commented 7 years ago

@lmmrssa @dogi I think I might know more details about why this happens. In the UI tests I make I have been waiting for links and buttons to become clickable. To do this Selenium polls the DOM I think, and the buttons etc. are listed as clickable before they can actually do anything because they depend on javascript/ jquery running in the background.

Would it be feasible to make the controls disabled until the js/jquery they depend on is finished loading and running? Or should we look for a way of checking if jquery / js are still busy from selenium? Like this example here.

waryhermit commented 7 years ago

@lmmrssa @dogi This is still an issue. Often times my bell app is locked up for 15 - 60 seconds, less in chrome. Even if I find a way to make codeceptjs intelligently wait until things are clickable, this isn't acceptable behavior from the users point of view, and to me indicates that there is processing being done on the UI thread, which should not happen.

Some questions...

Is there a quick solution you could add to make it more clear to the user and my tests that the UI is not able to be used yet, such as disabling the controls or making a loading icon appear?
Why is App.Router.PochDB(); set to run every 60 seconds in the index.html file
Why do we disable async so often? Any time we make a sync request the UI locks up until it the request resolves.

dogi commented 7 years ago

@waryhermit please if this also appies to @sente s version of Bell-Apps

http://sente.vi.ole.org:5979/apps/_design/bell/MyApp/index.html#login

the PRs this was:

waryhermit commented 7 years ago

Another thing to note: I do not have this problem if I test offline. If I disconnect my Ethernet cable and turn off WiFi the links are instantly usable.

waryhermit commented 7 years ago

@paulbert @mappuji @dogi Has any progress been made identifying the root causes of this bad behavior ?

dogi commented 7 years ago

@waryhermit so far not ;) but I assume something in the background is waiting on an answer of a request to nation