Arvados

Suggestions

• Perhaps the browser sends an event when it puts stuff in the input, like "input" or "change" or "autocomplete" -- in this case we just need to add this to the list of events that we listen for in our input→filters code.
• If not, perhaps $(document).ready(function(){$('input').trigger('input');}); will do it.

Implementation notes:

Added ready handler for input. To test, use Chrome (and probably Safari) to view a collection page and enter text in search box. Select one or two files from the results and combine to transition into the new collection page. Hit back button and you will see the search filter applied (provided your browser retained those search filters). Firefox does not retain user inputs (at least on my machine).

The application_helper file update is unrelated. As I was reading through the code, I learned that I can pass Collection as resource_class, rather than getting it from uuid. Since in this context, dataclass can be either Collection or File, I was not passing it and letting the object_readable method to get from uuid. Now that I learned that I can pass it instead, passing to avoid this unnecessary step.

1.5 comments at 4ccec6c:

Glad $('input').trigger('input'); works, but I think it should get a comment. (I know what it's for right now, but in 10 minutes it might look totally superfluous/mysterious, and no tests will fail if someone removes it...) Perhaps:

• This is needed to trigger input validation/synchronization callbacks because some browsers auto-fill form fields (e.g., when navigating "back" to a page where some text had been entered in a search box) without triggering a change or input event.

In case you're looking for bikeshed ideas, for this:

is_readable_input = object_readable attrvalue, Collection unless attrvalue.andand.empty?

How about:

is_readable_input = attrvalue.present? and object_readable attrvalue, Collection