If you are at the bottom and you hit the UP_ARROW key one time, the logic still thinks we are at the bottom, despite the component has clearly moved. Similar to the issue noted in the previous commit, this causes the page to increment incorrectly.
My wild guess is that the previous logic depends on the css height, so it might got broken due to css changes. Hopefully the new calculation is more robust and works for all cases.
---The bad scenario:
If you're at the bottom and you go up using UP_ARROW or HOME key, the coordinate is still at the bottom if we service the callback immediately. This causes 'contentWrapperAtBottomOfPage' to be true and we ended up incrementing the page unnecessarily (even for searches that no longer yield any extra results).
---Fix:
Fix by adding a delay. The value can probably be fine-tuned further.
---The issue:
When switching between tags, the selector defaults back to Trending even though you had another option already selected.
---Changes:
- 'orderParamUser' will store the last user state persistently. The persistent state is also made unique for each page (i.e. Your Tags and All Content will be unique).
- If the parent component passes in a specific order, that will be respected and will also become the new persisted value. One example is "Your Following", where it always starts at 'New'.
- Handled navigation history correctly
The test case:
- Enter "Your Tags" (assume start at 'Trending')
- Click 'New'
- Click 'Top'
- Back
- Back (it should return to 'Trending')
As the top page history does not have any "?order=" value, we ended up with a no-op for the last Back. 'orderParamEntry' is added to handle this.
Two issues:
1. Values not marked with __()
2. Split sentence.
For #2, it seems like there are translations that don't make sense when combined, because the values are being translated independently from full sentence in Transifex. Decided to just make it full sentences.
The MDE used in the "new" section has a parent width parameter to limit itself, while the MDE used in the "edit" section didn't.
Fix by limiting ".comment__body_container" to 80%, which takes into account the space taken by the author's avatar. This feels a little bit dirty since it's hard-coded. If there's a way to calculate the avatar width from here, it will be more robust.
