-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix thick scrollbar on filter menu #10835
Conversation
Unsure what happened with CI here, looks like some UTF-8 issue? |
@CirnoT What browser did you see this on? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should really be ensuring that a scrollbar doesn't need to be shown I think...
@silverwind What do you think?
@go-gitea/mergers feel free to dismiss my request changes if I have missed something here. |
Firefox, Windows 10
That might be little un-intuitive as there would be no indication to user that the area is scrollable. The scrollbar shows only when there's additional content hidden as it should, of course. |
*:not(select) {
scrollbar-width: thin;
} (taken from https://github.com/StylishThemes/Overlay-Scrollbars/blob/master/github-overlay-scrollbars.user.css) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above
I am afraid that would be hard to achieve, the width is decided by browser dynamically and I see no direct CSS stylesheet that would limit it. It is properly calculated based on the content, however the vertical scrollbar eats away at the pixels causing the element body inside to overflow. The one solution I could see helping it would be to remove If you believe this is worth blocking this PR for, I fully understand that and step down - this was supposed to be a quick fix for visual glitch with rather deep roots, I have no intentions on digging any deeper into trying to hack unfamiliar to me framework. |
For what it's worth, from quick check it does seem to be Firefox specific (though how much that is because of specifics in rendering engine and how much due to different scrollbar styling applied is unknown) and partially caused by |
Don't sweat about the CI failing. It happens from time to time. I've just restarted the task. |
Codecov Report
@@ Coverage Diff @@
## master #10835 +/- ##
==========================================
+ Coverage 43.56% 43.81% +0.24%
==========================================
Files 589 590 +1
Lines 82700 83387 +687
==========================================
+ Hits 36031 36535 +504
- Misses 42192 42331 +139
- Partials 4477 4521 +44
Continue to review full report at Codecov.
|
I can't seem to quite replicate the horizontal scrollbar. For some reason, this .repository .select-label .item {
max-width: 250px;
overflow: hidden;
text-overflow: ellipsis;
} This seems to be the rule that eliminates the horizontal on these. I think one solution could be to just ensure the Alternatively, can you post the HTML you see when the horizontal scrollbar is visible? |
The rule you linked does not apply to these elements as they are never inside container with class If you looked at screenshots you would see that the issue happens on "Assignee" where hint is not shown at all, as such it is red herring. Have HTML as requested, tho i have no idea why it would be necessary as it can be easily replicated.
|
Looking at it, it would seem that ensuring Because the hint uses
|
I think we can use this general approach to limit width of all direct children to .metas .menu > * {
max-width: 250px;
overflow: hidden;
text-overflow: ellipsis;
} Remove the Edit. Nevermind I see we're talking about different parts. I thought this was the issue sidebar. |
This seems to work for me: .metas .menu.transition > *, #issue-filters .menu.transition > * {
max-width: 250px;
overflow: hidden;
text-overflow: ellipsis;
} Fomantic-UI does not seem to have a distinct class for dropdowns, so hopefully the |
This does seem to work everywhere aside for the hint, which is not affected at all despite CSS being applied properly.
Is there any reason why we can't ensure |
I would aim for a more general solution for all dropdowns. According to this a dropdown is defined by .dropdown > .menu > * {
max-width: 300px;
overflow-x: hidden;
text-overflow: ellipsis;
} I'm pretty sure there are no dropdowns around that would require more width. Note I bumped the width by 50px as I think we can show a bit more of overly long labels and to possibly cover other dropdowns that might need more space. The .repository .filter.menu.labels .label-filter .menu .info {
width: 100%;
} |
Sounds good to me |
Should I close this PR and you will open new one with changes? @silverwind |
Yes, I'll open a new one soon. |
See #10897 |
* Fix scrollbar issues in dropdowns Fixes: #10835 * remove wrapping * grammar Co-authored-by: guillep2k <[email protected]>
Before:
![firefox_2020-03-26_12-32-26](https://user-images.githubusercontent.com/1447794/77643236-4e08d780-6f5f-11ea-9185-42e8fef8eef7.png)
![firefox_2020-03-26_12-32-45](https://user-images.githubusercontent.com/1447794/77643380-890b0b00-6f5f-11ea-9f84-9b8f02bcfd9d.png)
After:
![firefox_2020-03-26_12-38-38](https://user-images.githubusercontent.com/1447794/77643273-5e20b700-6f5f-11ea-998f-7de02b6d8fbb.png)
![firefox_2020-03-26_12-44-49](https://user-images.githubusercontent.com/1447794/77643409-9922ea80-6f5f-11ea-90fc-cbae9fb61c5e.png)