Duplicate filters on history nav#2622
Closed
bartonmcguire wants to merge 2 commits into
Closed
Conversation
Author
|
This build is failing during gem installation - but clearly the diff shouldn't affect this. It looks like builds for other recent and unrelated pull requests are failing for the same reason - leading me to believe that my diff does not introduce the issue. Does |
|
I can confirm the reported issue, which many of our users are finding to be troublesome. |
Member
|
Fixed by #2998. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There is a bug in which index page filters are duplicated when navigating back or forward in browser history. It's not a total show-stopper, but it's been bothering some of my users. And it is obviously incorrect/buggy behavior.
Repro steps:
Notice that there are now two "Created At" filters. Navigate forward and back again, now there are three... yikes!
This is because when navigating back the previously rendered filters are still on the page, but the inline script to
appendnew filters gets run again.The fix that I've come up with is to create an alternative function,
$.filters.init, which is called inline instead.initsimply checks whether any filters have been rendered already, and only builds filters for the array of options it is passed if they have not.I've updated specs that test the view helper construction of the inline script. However, I found no tests anywhere that cover the behavior of
$.filters, so I did not add tests for$.filters.init.