Where are you seeing this?

In the "File history" comments on a File page?

Yes, I can attach a screenshot of what I'm seeing if that helps?

Please :)

As per https://www.mediawiki.org/wiki/How_to_report_a_bug, information like this is useful

This is not a breaking out of container problem however. It's a "desktop site used on mobile" problem. For desktop sites, the mobile browsers emulate a larger screen. If the content is asking for more width, it will provide you more width (up to a maximum) and/or shrink other content. Since here a lot of width is requested, you will see the page at its maximum zoomed out level, with the maximum amount of width.

There is no real fix for this, other than making the desktop site properly responsive, which will likely upset lots of community members.

@TheDJ would it not be OK to simply wrap the text in word-wrap: break-word; in order to solve this?

Edit: note that the User column already appears to do this. See here

@TheDJ might it perhaps be possible to contain the Comment column with the same formatting as the User column?

@AlbanGeller yes you can, but as it says, it will break words. any words, so people might complain that words get broken at unexpected places for them.. it's a trade off

@TheDJ can we at least trial it out? Nobody has complained yet and if anyone does, it can be rolled back easily.

@Aklapper @Reedy any thoughts on whether such a fix (see above) would be doable?

See previous comments in this task

Tt can easily be trialed by the Commons community, by adding it to Commons' MediaWiki:Filepage.css

@TheDJ thanks for letting me know this. I'll make an edit request, but I'm not sure what specific code I should request?

Tt can easily be trialed by the Commons community, by adding it to Commons' MediaWiki:Filepage.css

@TheDJ can you please clarify? How can this be trialled?

@AlbanGeller I mean make an editrequest Common's MediaWiki:Filepage.css to have the following css added to it:

.filehistory td:nth-child(6) {
    word-break: break-word;
    min-width: 10em;
}

The min-width is needed to make sure the column doesn't become 1 letter wide and completely unreadable.

Current screenshot, does not appear to impact vector-2022

Clearly, it does affect vector-2022, as it overflows the page.

^Correction, agree - just at a different breakpoint. Seems like this is something that should be fixed in the layout for this page.

This is a special case of T66577: Large tables created by editors are not responsive and would be as fixed as it needs to be if that were resolved. In the meantime, this is one place the software could take care of the issue in some way, such as with

.listfiles .TablePager_col_img_description {
    word-break: break-word;
    min-width: 10em;
}

loaded somewhere in the PHP somehow. I don't think it's reasonable to push this on wiki since it can be managed and the location of the issue is more or less isolated to the one page.

Even with break-word, if you put a long url in there, its still going to overflow in some places. Really we should be looking at creating a completely different view..

Because.. why is this a table ?

• Does it absolutely have to be ?
• The history page of an article isn't...
• There aren't even row headers
• What will break if we just turn it into a nice list ?

Even more so for Special:ListFiles, why i heavens name is that a table (and an ugly one at that) ?

The answer is: No one looked at any of this since 2004.

In T270741#8576369, @TheDJ wrote:

Even with break-word, if you put a long url in there, its still going to overflow in some places. Really we should be looking at creating a completely different view..

Because.. why is this a table ?

• Does it absolutely have to be ?
• The history page of an article isn't...
• There aren't even row headers
• What will break if we just turn it into a nice list ?

The answer is: No one looked at any of this since 2004.

On the file page, I think these should be MCR kept in the history, but we've got 20 years of file uploads we'd need to 'move'. You know, whenever MCR....

It's otherwise appropriate to present these as a table IMO. The image itself could reasonably be a proper row header, but you could argue that should be for the date/time of upload. You can definitely sell me on removing the description in this context barring some sort of MCR migration, which is something that the normal history sees anyway, and current text can be Special:Searched.

Even more so for Special:ListFiles, why i heavens name is that a table (and an ugly one at that) ?

I have a hard time countenancing the existence of Special:ListFiles. While I'm sure it's useful, it's basically equivalent to Special:Allpages filtered to File namespace and a bunch of extra information I'm pretty sure it shouldn't have. You could sell me on having the image displayed itself, but the rest of it? Special:Search is a better way to identify current descriptions, Special:Log/upload better for seeing new uploads. Authorship feels marginal and/or it should probably contain all authors that have uploaded to that image name rather than just some initial one, but how important that is is questionable to me.

I guess both could be made to look like Special:NewFiles if we remove the description, which is the problem child in this task anyway.