Long "last commit" message overflows grid cell to the right. #14056

Closed
opened 2025-11-02 11:01:38 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @wolfbeast on GitHub (Jan 27, 2025).

Description

The last commit line in code view overflows the designated line if the commit message is long (it runs until the end of the outer grid).
This seems to be related to an unconstrained grid element in CSS.

Selector in question: #repo-files-table .repo-file-last-commit

Simple fix: add "width:100%" to that selector to ensure it is constrained and not growing out of bounds.

Screenshots

Image

Gitea Version

1.23.1

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

Windows 10 22H2

Browser Version

Pale Moon 33.5.1

Originally created by @wolfbeast on GitHub (Jan 27, 2025). ### Description The last commit line in code view overflows the designated line if the commit message is long (it runs until the end of the outer grid). This seems to be related to an unconstrained grid element in CSS. Selector in question: `#repo-files-table .repo-file-last-commit` Simple fix: add "width:100%" to that selector to ensure it is constrained and not growing out of bounds. ### Screenshots ![Image](https://github.com/user-attachments/assets/87fe8078-a691-489c-8057-ab3839f56055) ### Gitea Version 1.23.1 ### Can you reproduce the bug on the Gitea demo site? Yes ### Operating System Windows 10 22H2 ### Browser Version Pale Moon 33.5.1
GiteaMirror added the topic/uiissue/needs-feedbacktype/bug labels 2025-11-02 11:01:38 -06:00
Author
Owner

@wxiaoguang commented on GitHub (Jan 27, 2025):

Unable to reproduce it with Chrome and Firefox, are there some details about how to reproduce it only reproduces with Pale Moon, are there some standard differences? I think we need to figure out the HTML layout standard.

Chrome

Image

Firefox

Image

@wxiaoguang commented on GitHub (Jan 27, 2025): Unable to reproduce it with Chrome and Firefox, ~~are there some details about how to reproduce~~ it only reproduces with Pale Moon, are there some standard differences? I think we need to figure out the HTML layout standard. <details> <summary> Chrome </summary> ![Image](https://github.com/user-attachments/assets/efbab871-0780-4734-8369-b881d6bb4fd7) </details> <details> <summary> Firefox </summary> ![Image](https://github.com/user-attachments/assets/3f6cfd78-1362-4115-b788-e5adf5b84d81) </details>
Author
Owner

@wolfbeast commented on GitHub (Jan 27, 2025):

There are differences in how some of the standards are interpreted by different rendering engines. This seems to be one of them.
In the meantime I've done some further research into the relevant behaviour of different engines. CSS grid is very complex spec and there are plenty of differing nuances in it (especially when creating "pseudo-tables") and it seems the standard is also constantly being tweaked to be descriptive rather than defining (i.e. describing what the most-used engine does, in this case Chrome and every thing building on it).
I'm asking for a non-breaking solution here adding the suggested width to this element so it's more browser-agnostic.
In the meantime I've also looked into aligning Goanna (Pale Moon's engine) with the behaviour of other engines for parity and making life easier for you going forward, in lieu of spending a lot of time analyzing a standard and discussing ambiguity in it with Blink devs who are generally unwilling to make changes once set.

Specifying the width explicitly to be intended element width and preventing growth > 100% doesn't seem to influence Blink-based browsers (I've tested it on our repo instance where I've made this change in the static assets) so it's a free win for you.

@wolfbeast commented on GitHub (Jan 27, 2025): There are differences in how some of the standards are interpreted by different rendering engines. This seems to be one of them. In the meantime I've done some further research into the relevant behaviour of different engines. CSS grid is very complex spec and there are plenty of differing nuances in it (especially when creating "pseudo-tables") and it seems the standard is also constantly being tweaked to be descriptive rather than defining (i.e. describing what the most-used engine does, in this case Chrome and every thing building on it). I'm asking for a non-breaking solution here adding the suggested width to this element so it's more browser-agnostic. In the meantime I've also looked into aligning Goanna (Pale Moon's engine) with the behaviour of other engines for parity and making life easier for you going forward, in lieu of spending a lot of time analyzing a standard and discussing ambiguity in it with Blink devs who are generally unwilling to make changes once set. Specifying the `width` explicitly to be intended element width and preventing growth > 100% doesn't seem to influence Blink-based browsers (I've tested it on [our repo instance](https://repo.palemoon.org/MoonchildProductions/UXP) where I've made this change in the static assets) so it's a free win for you.
Author
Owner

@wxiaoguang commented on GitHub (Jan 27, 2025):

Hmm, I think adding min-width: 0; is the better (and proper) solution. It makes the flex won't exceed the x-axis. I tested it and it works with PaleMoon.

@wxiaoguang commented on GitHub (Jan 27, 2025): Hmm, I think adding `min-width: 0;` is the better (and proper) solution. It makes the flex won't exceed the x-axis. I tested it and it works with PaleMoon.
Author
Owner

@wxiaoguang commented on GitHub (Jan 27, 2025):

-> Fix flex width #33414

@wxiaoguang commented on GitHub (Jan 27, 2025): -> Fix flex width #33414
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#14056