* about the rdrama_rules, when I changed from http:// to https:// the other day, in some browsers it now displays the protocol tag which is ugly and inconsistent. Not sure why on some browsers it did not display "http://" before
* about the sorting: I will disable sorting on more table columns later on. This is all I can do right now
Reviewed-on: rDrama/rDrama#112
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
We currently cannot see (toggle the dropdown/button) reports that are hidden behind the "show more" (comments) button. This PR fixes that.
Example of what is happening without this PR:
1. open megathread. The thread is long includes hundreds of comments implying need to click "show more" (comments) button
2. without clicking any "show more" (comments) button, click the flaggers button on one of the first comments
3. flaggers are presented as expected
4. click the "show more" (comments) button at the end
5. click the flaggers button on one of the comments that was hidden behind the "show more" (comments) button
6. the button does nothing and has no event listenner associated
With this PR:
1. all flaggers buttons work regardless if hidden behind "Show More" (comments) or not. Tested up to two "Show More" (comments) buttons
I did the PR this way because the view_more button calls register_new_elements() and not bottom.js as a whole
There are other things using data-toggleelement like the undelete button on comments and the Preview button on /submit. Both of those still work as expected
Reviewed-on: rDrama/rDrama#111
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
fix-small-tisms that I had piled up in my todo
Reviewed-on: rDrama/rDrama#109
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
I noticed there are some over-interactive tables in general on rdrama. Particularly, multiple columns in the shop tables (awards and hats), which allow you to sort by buttons, icons, … The one page for user profile views also comes to mind, because it uses relative time since last visit, is paged server-side and browsers do not know how to sort that type of data anyway.
Also I noticed there are some tables that have disabled sorting by using <td> instead of <th> for the headers as is the case of the following pages:
* @uid/followed
* @uid/following
All of these situations are accounted for but need to be changed later in a different PR, because I can't right now.
For example, the "Buy" column of the shop can be changed to the following to disable sorting:
`<th class="disable-sort-click">Buy</th>`
Reviewed-on: rDrama/rDrama#107
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Small lil PR to reduce/minimize overscroll (aka scroll chaining) when scrolling to the end of scrollable modals. Also relevant to mobile
Primary targets:
- GIFs scrollable tabs body
- EMOJI scrollable tabs body
- AWARDS scrollable tabs body
Should (TM) apply to other scrollable modals if the same HTML structure is used
Very important notes (TM):
* this does not apply to non-scrollable modals (e.g. delete and report)
* this only applies to the body of the modal where scrollable content is usually located (as per selector). Example of when it does not apply:
* if we try to scroll near the search bar (e.g. on GIFs modal), we will still scroll the background
* if we make the modal non-scrollable (e.g. limited search in emoji or its tabs), there is no overscroll protection
Why I chose this implementation:
* I have implemented this recently when all browsers started supporting it in the last months of 2022
* we cannot just disable the main body/html element scrollbar because it is likely to create headache-inducing content redraw situations
* minimalistic and it is a relatively modern way to do it
* about 300% better than some client-side javascript spaghetteh to avoid content redraws
* methodical alternative is to reimplement site-wide modals/scrolling (LMAO)
* I did not apply it to .modal-body because it does not work when we scroll in the empty area on the sides of the scrollable area (which I always do).
Reviewed-on: rDrama/rDrama#100
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Kindly,
This fixes issue I created rDrama/rDrama#60 . Note that both z-indexes had to be removed because when I kept either of them, there was still z-fighting issues.
Considering that .dropdown-actions is used elsewhere, I tested the changes also on these pages and it still (TM) works on my machine (TM).
./files/templates/home_comments.html <----- Didn't test on /comments because disabled but it is same as search.html AFAIK
./files/templates/home.html
./files/templates/log.html
./files/templates/search.html
./files/templates/submission.html
./files/templates/userpage/header.html
Reviewed-on: rDrama/rDrama#96
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>