<!-- 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)).
```
* Init
* Update simple-page.scss
* Simplify
* Update simple-page.scss
* Delete loading.css
* Update some translations
* Remove some translations (still more to update)
* WIP translations - just need to confirm with friends
* Update/remove translations
* [JENKINS-73592] refresh buildhistory widget when page gets focus
* [JENKINS-73613] refresh buildhistory in all cases
refresh the buildHistory widget instantly when the window gets focus,
e.g. after switching browser tabs but also when one was in another
application and clicks in the browser window.
When the window is visible it will update even when it has no focus,
when the window is hidden no calls to the controller will be done.
Additionally the buildHistory will be updated when it is not on the
first page. So e.g. when someone deletes a build, changes the display
name or the description or when a build is still running the page gets
updated.
* [JENKINS-73668] fix stlying of rowSelectionController dropdown
ensure there is enough gap between entries
* style it as before with smaller dropdown button
* apply prettier
* 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
[JENKINS-73543] make icon in buttons in tables resizable
With #9131 the jenkins-table__button was replaced at certain places with
jenkins-button. But this change caused two regressions:
- The icon size for large table was almost the same as that for medium
tables
- The icons wrapped in jenkins-button were not resizable
- with small table the buttons overflowed the table cell
This change restores the old icon size for large tables and adds
additional css rules for jenkins-button inside tables so they are
properly resized and the padding is correct
* remove idle executors from widget
showing idle executors brings no value. They only blow up the widget.
Instead the busy/total number of executors are added behind the agent
name when the agent is online.
The executor name is kept intentionally to distinguish regular executors
from oneoffexecutors
* feedback
use an icon for oneoffexecutors (FlyweightTask), instead of using a
number for normal executors (which is also not really interesting).
When there are no agents and no builds running use the same text as when
collapsed to show that nothing is running.
* busy in widget header
* fine tuning styling
* icon-xs symbols
* show offline
* show collapsed with no executors
* fix css
* append tooltip to parent
---------
Co-authored-by: Daniel Beck <1831569+daniel-beck@users.noreply.github.com>
Tim Jacomb