Restyle file uploads to fit in with modern forms UI

[janfaracik]

A small PR to update the file upload control so that it fits in with the rest of forms. The button now resembles a standard .jenkins-button rather than the native OS one.

Before

After

Testing done

Go to a page with a file upload control, such as Plugin Manager -> Advanced.
Spot the file upload control.
Upload a file.
File uploads successfully.

Proposed changelog entries

• Restyle file uploads to fit in with modern forms UI

Proposed upgrade guidelines

N/A

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples).
  • Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@jenkinsci/sig-ux

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[NotMyFault]

Is it intended to truncate the file name? Looks a bit odd to me. So is the missing space between the button and the file to upload.

Maybe we should add a page to the design lib outlining that you should use the jenkins-file-upload class when accepting file inputs, rather than jenkins-upload or setting-upload 🤔

[janfaracik]

Is it intended to truncate the file name? Looks a bit odd to me

Good spot, hadn't tried it with a really long file name - just needed to set the width to 100%.

So is the missing space between the button and the file to upload.

Yeah it's a limitation with the upload input :/ I've tried everything I can think of but still no additional padding. It's a limitation in Safari, just tried it in Chrome and the margin property works as expected 🎉

Maybe we should add a page to the design lib outlining that you should use the jenkins-file-upload class when accepting file inputs, rather than jenkins-upload or setting-upload 🤔

Definitely 👍

[daniel-beck]

Would it not be easier / more backwards compatible to apply different rules for input type="file" rather than requiring every declaration to be adapted to what amounts to redundant information? Or would there be input type="file" that should not have class="jenkins-file-upload"?

[uhafner]

Would it not be easier / more backwards compatible to apply different rules for input type="file" rather than requiring every declaration to be adapted to what amounts to redundant information? Or would there be input type="file" that should not have class="jenkins-file-upload"?

Actually this calls for a jelly template f:fileButton as well (encapsulation).

[daniel-beck]

Actually this calls for a jelly template f:fileButton as well (encapsulation).

Not opposed (I've previously impersonated a broken record asking for Jelly components instead of changing CSS classes around), but only doing that still wouldn't take care of existing upload fields.

[timja]

Would it not be easier / more backwards compatible to apply different rules for input type="file" rather than requiring every declaration to be adapted to what amounts to redundant information? Or would there be input type="file" that should not have class="jenkins-file-upload"?

see https://weekly.ci.jenkins.io/design-library/Conventions/. All new CSS is to be name-spaced and prefixed to prevent clashed with other libraries etc.

If we were to modify the default styling then this would be the only component I'm aware of doing it that way and would be inconsistent with everything else.

[timja]

I've filed PRs with all plugins that look to be maintained using this search: https://github.com/search?q=org%3Ajenkinsci+input+type%3D%22file%22+NOT+repo%3Ajenkinsci%2Fjenkins&type=code&p=1

[NotMyFault]

Looks good, left some optional feedback for consideration.

[timja]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

[jglick]

I've filed PRs with all plugins that look to be maintained using this search

Looks like you missed file-parameters-plugin, because you did not search for an intervening attribute (name in that case).

[jglick]

Optional I guess?

You could just copy unknown tag attrs to the HTML tag. There is some Jelly/Stapler trick to do that.

[timja]

Yes, use="required" denotes mandatory.

if can you point to it that could be useful although likely unneeded

[strangelookingnerd]

You could just copy unknown tag attrs to the HTML tag. There is some Jelly/Stapler trick to do that.

Second this as it is important for my use case.

[jglick]

jenkins/core/src/main/java/hudson/util/jelly/MorphTagLibrary.java

Lines 24 to 32 in 7c18855

	* Tags from this namespace ("jelly:hudson.util.jelly.MorphTagLibrary") behaves mostly like literal static tags,
	* except it interprets two attributes "ATTRIBUTES" and "EXCEPT" in a special way.
	*
	* The "ATTRIBUTES" attribute should have a Jelly expression that points to a {@link Map} object,
	* and the contents of the map are added as attributes of this tag, with the exceptions of entries whose key
	* values are listed in the "EXCEPT" attribute.
	*
	* The "EXCEPT" attribute takes a white-space separated list of attribute names that should be ignored even
	* if it's in the map.

jenkins/core/src/main/resources/lib/form/textbox.jelly

Lines 107 to 113 in 7c18855

	<m:input xmlns:m="jelly:hudson.util.jelly.MorphTagLibrary"
	class="jenkins-input ${attrs.checkUrl!=null?'validated':''} ${attrs.autoCompleteUrl!=null?'auto-complete':null} ${attrs.clazz}"
	name="${name}"
	value="${value}"
	type="text"
	placeholder="${placeholder}"
	ATTRIBUTES="${attrs}" EXCEPT="field clazz" />

[timja]

Thanks, @strangelookingnerd what is missing that you need?

[strangelookingnerd]

See https://github.com/jenkinsci/custom-folder-icon-plugin/blob/master/src/main/resources/jenkins/plugins/foldericon/CustomFolderIcon/config.jelly#L34

I'm adapting the size (for visual reasons) and add an ID to add a change event in the following <script> section
https://github.com/jenkinsci/custom-folder-icon-plugin/blob/5f60c7af85f7dfd56caca7e6ce392e70442ab616/src/main/resources/jenkins/plugins/foldericon/CustomFolderIcon/config.jelly#L61-L69

Maybe this is the wrong approach but without the ID my use case breaks.

[jglick]

That source file should be st:adjunct and probably Behaviour.specify but that is another story.

[timja]

Styling should be done via classes and not inline css, I added support for an ID because of your plugin but you could also do that via a CSS class anyway