In #147 we modified the reply sending logic so that it first sets hyperlinks to a temp value and rely on promises to fill in hyperlinks after loading finishes.

However, the procedure may fail and cause forever polling scenario like this:
https://cofacts.g0v.tw/reply/H4TBinABWiTSPYAZPHxn

Needs further discussion on

• How many replies are affected
• How this can be mitigated

Frontend doesn't have enough unit testing. These are the parts that should be tested in priority:

State

• video_debate/comments/reducer.js
• video_debate/comments/selectors.js
• video_debate/statements/reducer.js
• video_debate/statements/selectors.js
• video_debate/video/reducer.js

Components

TODO

As-is

1. After inputting reason, the reason submission button jumps up and cancels the first click
2. During submission, there is no visual feedback indicating that the reply request is being sent

To-be

1. Don't change reason input height when reason input is

As-is

From https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w?both#%E5%9B%9E%E6%87%89%E3%80%8C%E6%B2%92%E6%9C%89%E3%80%8D%E7%9A%84%E6%AD%A3%E8%A9%95

看來是因為我們在使用者回報一個回應有用時，會這樣問使用者：

這個提問導致使用者輸入「沒有」然後送出。但在 Cofacts 網站上，就會看到有一堆人 upvote 然後又表示「沒有」，有點沒頭沒尾。
![image](https://user-ima

Text FR

Différence entre les commentaires et les sources : les sources qui confirment ou réfutent la citation seront affichées à tous les utilisateurs de l’extension navigateur durant la lecture de la vidéo. Les commentaires quant à eux peuvent contextualiser l'inform

• Show a "Refresh Cache" button in extension popup to manually refresh the cache
• Display the last refresh date
• Add a select to set the max refresh interval: 5 / 15 / 30 minutes, 1 / 6 / 24 hours, or never (only manual refresh)