fix(files): fixed breadcrumbs dissapearing on narrow screens

[emoral435]

• Resolves opening sidebar hides broadscrombs totally with some screen resolutions #44120

Summary

NcBreadcrumbs already handled for when breadcrumbs are too long for the view-width by making the unmaintainable breadcrumbs composed into a drop-down list, so we only have to care about hiding the breadcrumbs on small view ports. I tried 420, as that is what we use everywhere for standard, but 400 worked much better with the styling of the navbar.

Screenshot

firefox_oxj23hr7fI.mp4

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[emoral435]

/backport to stable28

[skjnldsv]

@emoral435 now, even on wide screens, we hide the breadcrumbs if any upload is ongoing, this seems like a regression?

My suggestion

		// Hide breadcrumbs if an upload is ongoing
		shouldShowBreadcrumbs(): boolean {
			// If we're uploading files, only show the breadcrumbs
			// if the files list is greater than 768px wide
			if (this.isUploadInProgress) {
				return this.filesListWidth > 768
			}
			// If we're not uploading, we have enough space from 400px
			return this.filesListWidth > 400
		},

cc @szaimen too
Because right now, we cannot browse files while an upload is ongoing, I think this is an issue :)

[emoral435]

@skjnldsv Agreed 👍 Will make a PR to fix this. However, I will test to see if the last return condition is even needed, as within somewhere in FilesList there already is a feature to truncate the breadcrumbs around that view port width anyways, so having two places hide the breadcrumbs just increases the complexity / amount of things we would have to find and then change in the future in case we decide to change this :)