Manually trigger change event when user focused out an input if the d…

[juzen2003]

• Were any Django, import pipeline, table_schema, or dictionary files modified? N
  • Database used: opus3_test_200517
  • All Django tests pass: Y
• Were any JavaScript or CSS files modified? Y
  • JSHINT run on all affected files: Y
  • Tested on Chrome, Firefox, Safari, and iOS: Y (Remember to test all browser sizes)
  • Tested for race conditions (with delayed API calls if applicable): NA

Description of changes: When the user removed input value and focused out an input, sometimes the "change" event will not be fired. We manually fire the "change" event in the "focusout" event handler when this situation happened.

Known problems: None

[juzen2003]

The root cause for the issue is the following (this is the default behavior of an input tag):

1. When the user selected a preprogrammed range item, we used .val() to set the min/max input values and manually triggered change event (.trigger("change")) for both inputs.
2. After both change events are done, we are still focus in the min input. However the min input still treats the previous input value (the value when we first focused in the input before step 1) as the old value. And it will use this old value for comparison to determine if a change event should fire when the user changes the input value.
   • This is the default behavior of an input tag, please see the experiment in jsfiddle with the following steps: https://jsfiddle.net/xa56eb03/17/
     1. Focus into input 1, type "6" and hit enter. Now "6" is remember as the old value and we are still in focus.
     2. Delete "6" and type "x" to automatically update input 1 (using .val()) to "89" and programmatically trigger a change event.
     3. Now input 1 has "89" after the change event, and we are still in focus. However, input 1 still treat "6" as the old value.
     4. Delete "89", type "6" again, and don't hit enter. Now we focus out input 1.
     5. From console, we can see there is only focusout event and no change event happened.

• To bypass this default behavior, all we need to do is to focus out & in again at the end of iii. so that input 1 will remember "89" as the old value instead of "6".

[rfrenchseti]

Hmmm actually your change breaks something else. Apparently normalize input isn't working on the min field anymore. For example, go to ring radius. Type "b ring" and click on it. Notice that the "min" still has a comma, but the "max" doesn't.

It's worse than that, though. Type "b" and hit enter. Get the red box and all ?. Now go back and select "b ring" and click on it. The proper values will be filled, but the ? will still be present everywhere.

[juzen2003]

• Perform the step of re-focusing into input after normalize input validation to make sure normalized values are updated in input fields. This will solve the issue of comma in min.
• "?" didn't go away after changing to a valid search. This issue exists in the master too. We now set opus.force_load to true when there is an invalid input value. This is for the case when we change a valid search (result1) to an invalid search (result2), and later on change back to result1, there will be a search triggered again to put back the valid green hints instead of keeping "?".

[rfrenchseti]

• Database used: opus3_test_200517
• All Django tests pass: NA
• JSHINT run on all affected files: Y
• Tested on Chrome, Firefox, Safari, and iOS: Y (Remember to test all browser sizes)
• Tested for race conditions (with delayed API calls if applicable): Y