Add `remove_alert_word()` function which uses the correct data flow
while removing an alert word.
`alert_words_ui.js` was structured differently from most of the other
settings. It was not using the triggers from the server for running
the success/failure handlers.
We remove the `page_params.alert_words` since `alert_words.words`
is the sole source of alert words. Use of `page_params.alert_words`
could lead to bugs when alert words are updated since it is not updated.
This doesn't change the alerting UI logic, it just turns
alert_words_ui into a module and calls the setup code from settings.js
when the settings page is rendered.
(imported from commit 05f95383b046086641280f82f648be58688efe61)
This fixes a mild regression in 6bd2a0315ff56a20027074d65ccaa094bd35e63f,
which fixed a bigger bug. That change added the event parameter to
add_alert_word(); this change updates one of the callers to now
supply it.
(imported from commit c6375abb8bd22d12c538cd7439462aae4665ee38)
The global in question was `event`, set to:
MouseEvent {dataTransfer: null,
toElement: button.btn btn-mini add-alert-word,
fromElement: null, y: 442, x: 763…}
in Chrome. This does seem to be the correct event.
In Chrome, this global variable existed, so the code path didn't error
out. In Firefox, the global variable didn't exist, causing adding
alert words to fail.
(imported from commit 6bd2a0315ff56a20027074d65ccaa094bd35e63f)