headerCommandPaletteButton undefined when JenkinsHeader not loaded

[jglick]

Automated test suites (PCT + ATH) run by CloudBees CI against recent trunk code turned up numerous cryptic JavaScript failures; for example the button in a credentials dropdown to open a dialog to create new credentials would just report an error about missing window.dialog and do nothing, and so all acceptance tests using credentials failed. I tracked these down to an initial error

Uncaught TypeError: headerCommandPaletteButton is null
    command_palette_init index.js:40
    7807 app.js:11

In most cases this was because CloudBees CI overrides JenkinsHeader (#5909) and the replacement does not currently include the same search box functionality as in Jenkins. #7569 however included initialization code presuming that (for example) button-open-command-palette existed, and did not gracefully skip execution if it was absent, such as if a custom header were in use.

In another case I found, a page was using <l:layout type="full-screen" …> (#2445) which also omits this search box (but otherwise loads stock JavaScript). In fact Jenkins OSS does this in the setup wizard, and you can see this error by running that. It is mostly harmless in that context: stock JS fails to initialize, but was not being used anyway, and so the only apparent symptom is a warning in the browser log. An HtmlUnit-based test caught this.

Testing done

New functional test here, and also seems to correct automated test failures in CloudBees CI.

Proposed changelog entries

• Since 2.489, JavaScript errors could be seen in some Jenkins pages omitting the usual header bar, such as the setup wizard.

Proposed upgrade guidelines

N/A

Desired reviewers

@janfaracik

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

Maintainer checklist

Preview Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. 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).
6. 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).

[jglick]

Without fix:

TypeError: Cannot call method "addEventListener" of null (http://…/jenkins/static/…/jsbundles/app.js#1069)

[janfaracik]

Thanks for this :)

[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!