The issue is in the dropdown_selector component, which stores data as a
`data-index` element on a dropdown. This means all values are cast to
strings in anything using that dropdown, which means we need to
unstringify on the `handleChange` function that (up in the component)
calls the `getAttribue` function. Anyway this means we can remove
terrible hacks in multiple places.
When opening a page such as /web/timelines/home in a desktop browser, the
cursor was automatically placed in the textarea of the compose form.
When using the keyboard for navigation (using a browser plugin like vimium or
vim vixen, or just to hit 'space' to scroll down a page), you have remember to
leave the field before using that.
Since you only visit the page to write a new post some of the time, this PR
attempts to have nothing focused initially (and require the user to click or
e.g. use 'tab' to focus the textarea).
Tested:
* /web/timeslines/home no longer autofocuses the compose box
* pressing the 'n' hotkey still focuses the compose box
* clicking 'reply' for a post still focuses the compose box
* replying to a CW'ed post still focuses the compose box
* introducing the CW field still focuses the CW field
* introducing the CW field for a reply still focuses the CW field
* removing the CW field still focuses the compose box
* /web/statuses/new still autofocuses the compose box
fixes#15862
- Change name of conversations column in web UI
- Change hotkey for opening conversations column from `g d` to `g c` in web UI
- Remove shortcuts for creating direct-visibility statuses from web UI
When opening a page such as /web/timelines/home in a desktop browser, the
cursor was automatically placed in the textarea of the compose form.
When using the keyboard for navigation (using a browser plugin like vimium or
vim vixen, or just to hit 'space' to scroll down a page), you have remember to
leave the field before using that.
Since you only visit the page to write a new post some of the time, this PR
attempts to have nothing focused initially (and require the user to click or
e.g. use 'tab' to focus the textarea).
Tested:
* /web/timeslines/home no longer autofocuses the compose box
* pressing the 'n' hotkey still focuses the compose box
* clicking 'reply' for a post still focuses the compose box
* replying to a CW'ed post still focuses the compose box
* introducing the CW field still focuses the CW field
* introducing the CW field for a reply still focuses the CW field
* removing the CW field still focuses the compose box
* /web/statuses/new still autofocuses the compose box
fixes#15862
* Add editing for published statuses
* Fix change of multiple-choice boolean in poll not resetting votes
* Remove the ability to update existing media attachments for now
* Add confirmation modal when closing media edit modal with unsaved changes
* Move focal point media state to redux so it does not get erased by confirmation dialog
* Change upload modal behavior to keep it open while saving changes
Instead of closing it immediately and losing changes if they fail to save…
* Make it work with react-intl 2.9
* Various dropdown code quality fixes
* Prepare support for privacy selection in boost modal
* Add dropdown for boost privacy in boost confirmation modal
Darius Kazemi
Misty De Meo
Christian Schmidt
Claire
Tianwei Dong
Eugen Rochko
Mashiro
Renaud Chaput
nachtjasmin
fusagiko / takayamaki
Nick Schonning
Arnout Engelen
Takeshi Umeda
Mélanie Chauvel
abcang
ThibG
kedama
Emma Winston