I skimmed through the issues but couldn't find anything that seemed related to this. I use fivestar in my procon module to rate several arguments and sort them by rating. The problem is that when a user has voted and reloaded the page to reflect the new sorting of arguments, the new number of highlighted stars is not updated, instead it inherits the number of stars the argument had which was on the same spot on the page.

I'm pretty sure this is due to how Firefox caches radio buttons on a page. Opera and IE doesn't have this problem.

To reproduce: create a view which lists a fivestar enabled content type, full node, sort it by average percent. Rate a node, refresh the page. Look on the number of highlighted stars and the average rating, it shouldn't be the same. In Firefox you need to Ctrl-F5 to update the display of stars.

I wonder if this would be solved by instead using a select form.

I also noticed caching problems when voting with javascript turned off, which is less critical, but still. After submitting a vote the widget was not updated.

Comments

quicksketch’s picture

quicksketch
he/him
commented

Firefox does this sort of caching for all form elements that I know of. Reloading the page will always keep the same form values, I think it's more of a feature than a bug. :)

Could you use drupal_goto() to cause a new page request rather than reloading the page? I'm not familiar with your module's approach or why you would ever reload the page, but not want the form elements to stay intact.

anders.fajerson’s picture

anders.fajerson commented

Thanks for the reply. True, a page reload is rather rare I guess, and most obvious when you do development as you quite often reload the page to see the order of e.g. arguments change (see http://drupal.telematicsfreedom.org/?q=node/5 for an example use). Then a feature in Firefox becomes a bug in Fivestar ;)

The "original" jRating implementation don't use a form element to get the number of highlighted stars (I think I remember it used a "title" attribute). But it might be a step back in other areas to use that approach instead, I don't know.

quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Closed (won't fix)

I'm marking won't fix because saving the fivestar value in a place other than the form values will end up breaking the "Back" button in many browsers. (Leave the page then come back). Users may expect or want forms to maintain their values when going foward then back, and I'd prefer to keep all the normal functionality of forms in place for fivestar.

FiReaNGeL’s picture

FiReaNGeL commented
Status: Closed (won't fix) » Active

I have to reopen this to try to find a solution, as I have a use-case in which page reload are frequent. No need for an official patch if you want to keep fivestar as-is, but I think a solution and some documentation about it (as it is a fairly rare problem) should be enough.

So I have a page with a list of 10 nodes and their associated fivestar fields (summoned by a call to theme('fivestar_widget', fivestar_widget_form($node)). This list of 10 nodes consist of the top recommendations for a user - it is frequent for them to reload the page to get new recommendations after they rate all 10 nodes. As it is, after a reload, ratings are applied from the previous page for yet-to-be-rated nodes. Problem exists only in Firefox.

FiReaNGeL’s picture

FiReaNGeL commented

This article: http://www.siafoo.net/article/66 describe a solution. It's pretty simple, just add autocomplete="off" to the parent <form>. However, the <select> fields of fivestars are not wrapped in a <form> element. I'm not a FAPI wiz so is there any way to do that?

FiReaNGeL’s picture

FiReaNGeL commented

Fixed: I just called it a the theme level using : '<form autocomplete="off">' . theme('fivestar_widget', fivestar_widget_form($node)) . '</form>'. Might want to add this to the documentation somewhere. Thanks for the awesome module!

ericduran’s picture

ericduran commented
Status: Active » Closed (won't fix)

I'm going to close this issue as wont fix. This is for an unsupported version of fivestar and I can't seem to reproduce this issue.

FiReaNGeL’s picture

FiReaNGeL commented
Version: 5.x-1.7 » 7.x-2.x-dev

Just to be clear, the bug was occurring for me in the latest 7.x branch.