* Add abort support to FormChecker delayed checks
Support optional AbortController/AbortSignal in FormChecker.delayedCheck, skip aborted queued checks, and handle aborted/failed requests without stalling queue processing. Add regression test covering cancellation of outdated checks.
* Update test/src/test/java/hudson/util/FormFieldValidatorTest.java
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Address review feedback on FormChecker abort handling
Guard non-GET URL parsing when no query string is present, prevent schedule queue stalls on synchronous sendRequest failures, and make the regression test wait for queue drain instead of fixed timing.
* Use JS based test instead of hacky htmlunit test
---------
Co-authored-by: Kevin <kevin@Kevins-MacBook-Pro-3.local>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Tim Jacomb <timjacomb1@gmail.com>
* Update eslint monorepo to v10
* Assign buildInfo a useful initial value to avoid ESLint useless assignment warning
* Ignore useless assignment warning on intentional null of variable
https://stackoverflow.com/questions/10864544/javascript-gc-and-assigning-objects-to-null
notes that this is a common technique to release references to JavaScript
objects.
https://stackoverflow.com/questions/6326778/javascript-memory-leaks-why-would-assigning-object-to-null-work
also has a good discussion of the technique for more exotic cases.
* Ignore ESLint useless assignment warning to avoid added code complexity
The useless assignment probably could be eliminated, but the later
conditionals will probably make the resulting code more difficult to read.
Better to keep the code simple to read and accept that we suppress the
ESLint warning.
* Ignore ESLint useless assignment warning for code consistency
The p variable is used as a distinct counter in this code and each call
that references it also increments it. The last call could be replaced
by `p + 1` instead of `++p`, but the next addition after that would then
need to change this line to `++p` and adjust the newly added line to
`p + 1`. The code is easier to read with the consistent use of `++p`.
* Ignore ESLint useless assignment warning to avoid added code complexity
https://github.com/jenkinsci/jenkins/pull/26294#discussion_r2795027889
recommends the revert. No problem for me to switch from a change of
initialization order to a comment.
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Mark Waite <mark.earl.waite@gmail.com>
* [JENKINS-76249] Fix form submission when a dropdown changes and the web response is slow
calling renderOnDemand can cause the dom to be manipulated
aynchronouslyi due to function calls going to the Jenkins server (e.g.
stapler/bound/xxx/render). When this occurs if there is a subsequent change to the
dropdown selection before this completes, when the HTML is finally
obtained from Jenkins it is inserted into the DOM, but it is inserted as
if it is still the selected option (ie it is not disable for the form).
renderOnDemand takes a callback function that will be called when the
DOM manipulation is complete, however the updateDropDownList did not
pass any function.
We now pass a function that manipulates the just added HTML if the
selected item is in fact no longer selected.
* Update war/src/main/webapp/scripts/hudson-behavior.js
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
---------
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
When one clicks on Add or Edit description, it is not possible to cancel
this. The only action to revert from here is to reload the page. This is
bad UX.
This adds a Cancel button to overcome this.
<!-- Comment:
A great PR typically begins with the line below.
Replace XXXXX with the numeric part of the issue ID you created in Jira.
Note that if you want your changes backported into LTS, you need to
create a Jira issue. See
https://www.jenkins.io/download/lts/#backporting-process for more
information.
-->
See JENKINS-75100
Now that the [disable by default of
YUI](https://github.com/jenkinsci/jenkins/pull/10045) has been released
for ~1 month with no complaints its time to start thinking about
removing YUI itself.
We're passed the baseline cut-off for the next LTS which was what
@MarkEWaite requested that I wait for before removing YUI fully
What I've left:
* I've removed CSS where I think its safe but I haven't removed all
mentions of `yui`.
* `l:yui` I've changed it to do nothing but its used in a few
unmaintained plugins, I could remove this, thoughts?
* There's a few TODOs that say they could be cleaned up after yui was
removed for the component, but hasn't been done yet
ATH passed:
https://github.com/jenkinsci/acceptance-test-harness/pull/1884
Bom: https://github.com/jenkinsci/bom/pull/4176
<!-- Comment:
If the issue is not fully described in Jira, add more information here
(justification, pull request links, etc.).
* We do not require Jira issues for minor improvements.
* Bug fixes should have a Jira issue to facilitate the backporting
process.
* Major new features should have a Jira issue.
-->
### Testing done
Clicked around a number of pages and didn't see anything wrong.
<!-- Comment:
Provide a clear description of how this change was tested.
At minimum this should include proof that a computer has executed the
changed lines.
Ideally this should include an automated test or an explanation as to
why this change has no tests.
Note that automated test coverage is less than complete, so a successful
PR build does not necessarily imply that a computer has executed the
changed lines.
If automated test coverage does not exist for the lines you are
changing, you must describe the scenario(s) in which you manually tested
the change.
For frontend changes, include screenshots of the relevant page(s) before
and after the change.
For refactoring and code cleanup changes, exercise the code before and
after the change and verify the behavior remains the same.
-->
### Proposed changelog entries
- Remove the Yahoo! User Interface library
<!-- Comment:
The changelog entry should be in the imperative mood; e.g., write "do
this"/"return that" rather than "does this"/"returns that".
For examples, see: https://www.jenkins.io/changelog/
Do not include the Jira issue in the changelog entry.
Include the Jira issue in the description of the pull request so that
the changelog generator can find it and include it in the generated
changelog.
You may add multiple changelog entries if applicable by adding a new
entry to the list, e.g.
- First changelog entry
- Second changelog entry
-->
### Proposed upgrade guidelines
N/A
<!-- Comment:
Leave the proposed upgrade guidelines in the pull request with the "N/A"
value if no upgrade guidelines are needed.
The changelog generator relies on the presence of the upgrade guidelines
section as part of its data extraction process.
-->
```[tasklist]
### 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](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)). 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](https://www.jenkins.io/doc/developer/security/csp/)).
- [ ] 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
@mention
<!-- Comment:
If you need an accelerated review process by the community (e.g., for
critical bugs), mention @jenkinsci/core-pr-reviewers.
-->
Before the changes are marked as `ready-for-merge`:
```[tasklist]
### Maintainer checklist
- [ ] 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](https://github.com/jenkinsci/jenkins/pull/4387)).
- [ ] 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](https://issues.jenkins.io/issues/?filter=12146)).
```
* Use standard dropdowns for autocomplete
* Debounce autocompletion, limit to 10 suggestions, allow tab
* Keyboard navigation improvements
Co-authored-by: Tim Jacomb <timjacomb1@gmail.com>
* Autocomplete: use the same width as the parent field
* Prevent browser autocomplete, do not hide on field click
* Use !==
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
---------
Co-authored-by: Tim Jacomb <timjacomb1@gmail.com>
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
* remove YUI from ensureVisible
replace usage of YUI with plain javascript in the ensureVisible method
The current logic seems to have no effect, so it is changed in the
following
When the element is bigger then the current viewport height, scroll so
that the element is at the top.
If the elements is smaller than the viewport height and the bottom is
outside scoll so that the bottom is at the lower end of the viewport.
Otherwise no scrolling is needed the element is already completely
inside the viewport.
* apply prettier
* remove body.scrollTop
* move the add/edit description button to the app-bar
So far rhe add/edit description button is rendered as button on its own
line to the far right. This leads to additional space the description or
the title and the following content.
This change moves the add/edit description button to the app-bar where
applicable (jobs, runs, computers, users). For views it stays as it is
as they don't have title/app-bar. One also can't just allow to change
the description via the configure page as the All View has no configure
page.
* make secondary button
* feedback
- fix permission in job page
- don't show the button for built-in node
- improve jelly doc
* [JENKINS-60866] Apply Stapler update for CSP-compliant st:bind
* [JENKINS-60866] Make renderOnDemand CSP-compliant
* Thanks Spotless
* Make Stapler incrementals work
* Update Stapler to new incremental
* Fixup bad merge
* Update Stapler, add test demonstrating st:bind working
* Address review feedback
* Add test for null bind, update Stapler
* Checkstyle
* More tests
* Use released Stapler
---------
Co-authored-by: Daniel Beck <daniel-beck@users.noreply.github.com>
Co-authored-by: Basil Crow <me@basilcrow.com>
* [JENKINS-69113] renovate progressBar
The progressbar used at various places is replaced by a div/span
compbination and gets a new styling that is in sync with other ui
elements. Mainly it has rounded corners.
The bar is always animated opposed to old behaviour where it was only
animated when the estimated remaining time was unknown. Animation is now
based on css and no longer a gif.
All colors are defined via variables so they can be adjusted by themes.
The build progress bar shown on run and console views is now updated
dynamically.
The progress bar used in progressive rendering is doubled in size to
make it more prominent that it is still running (See [JENKINS-72138],
this doesn't solve the problem but might lower the chance that people
reload the mentioned page because they think nothing happens).
* apply prettier
* scss style
* set status url
the parameters page also includes the buildCaption.jelly. But the js is
using a relative url thus accessing `statusIcon` fails.
Store status url in the div and read from there.
* apply behaviour so tooltip is shown after icon update
fix url
* incorporate feedback
use existing colors
only animate when unknown or with flag
animate via build caption and progressive rendering
* adjust class name
* adjust bg color
* fix style
* sRGB
* avoid j:out
---------
Co-authored-by: Alexander Brandes <mc.cache@web.de>
* readonly mode for f:select
when enabling readonly mode with the extended read permissions plugin
the places where an f:select is used are not replaced.
* apply prettier
* apply lint issues
JENKINS-72505 f:validateButton finds selected radio button
Co-authored-by: Mark Waite <mark.earl.waite@gmail.com>
Co-authored-by: Alexander Brandes <mc.cache@web.de>
move link elements to head
fixes JENKINS-72196 when in a form there are repeatables that both
contain a codemirror config via a textarea. When deleting the first
of those it can happen that the link elements importing the css for
codemirror are defined in a div that gets deleted. This effectively
removes the css from the DOM tree, so that other textareas afterwards
that also require the codemirror css are no longer styled properly.
The Behaviour uses a high negative value for the priority so that the
move of the link elements is applied before any other behaviour jumps
in, e.g. hetero-list and repeatable add the elements to the dom via
jelly of all things can that can be added and later remove them from the
dom and keep them in memory.
Guruprasad Bhat