-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inline form element path #5926
Inline form element path #5926
Conversation
core/src/main/resources/jenkins/formelementpath/FormElementPathPageDecorator/footer.jelly
Outdated
Show resolved
Hide resolved
core/src/main/java/jenkins/formelementpath/FormElementPathPageDecorator.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whether it should be enabled by default or with a system property
No strong opinion. Seems like it would be simpler overall to have this enabled unconditionally, so we could inline these additions into regular controls (probably generated server-side) rather than all these tricks with Behavior
. If we are concerned about HTML bloat and do not want it on by default, then it could be gated by a system property, defaulting to Main.isUnitTest
perhaps.
core/src/main/resources/jenkins/formelementpath/form-element-path.js
Outdated
Show resolved
Hide resolved
core/src/main/resources/jenkins/formelementpath/form-element-path.js
Outdated
Show resolved
Hide resolved
} | ||
|
||
// expose this globally so that Selenium can call it | ||
window.recomputeFormElementPath = applyAll; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this blow up somehow if the plugin is also installed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I plan to bump the baseline of the plugin and empty it out initially so this shouldn’t really matter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it wouldn't blow up anyway just last one to register would win
I've removed all the prototype.js code, we could inline this into |
applyAll(); | ||
|
||
// run this periodically to cope with DOM changes | ||
window.setInterval(applyAll, 1000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is what I'm most worried about having it on by default, every second recalculating the paths.
I tried removing it but its needed for repeatable elements to have the index added and re-calculated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jenkins already has runtime performance issues and periodic queries, I would avoid this as much as possible.
I'd suggest maybe registering this as a layout update callback (
var layoutUpdateCallback = { |
repeatable
is missing I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's already registered a couple of lines down, I'll take a look at adding it to repeatable to see if it removes the need for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should probably fix it for most plugins. Don't know if it's a problem that rogue plugins with custom widgets do not have this tbh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jenkins already has runtime performance issues and periodic queries, I would avoid this as much as possible.
As in #5926 (review) you should either
- Add the new HTML attributes or whatever unconditionally during Jelly generation, deleting all the JavaScript hacks, or at least as part of
buildFormTree
so it happens synchronously if and when a form is submitted. - Or disable all of this by default in production code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will probably disable by default but also look to add repeatable to layout update callback so the timer bit can be removed.
The timer bit made debugging this code a pain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe start with the current code copied-and-pasted from the plugin but disabled by default. That at least solves the immediate issue, we can gut the plugin, and simplify ATH to not try to load it.
Then as a follow-up look into whether the actual behavior can be simplified by inlining into lib/form/*.jelly
and/or hudson-behavior.js
.
Review comments should be all addressed now. a PR to adjust ATH: |
https://github.com/jenkinsci/acceptance-test-harness/pull/712/checks?check_run_id=4291377477 shows that something here isn't working, likely it's the removal of the run every second. I'll see if there's a fix otherwise I'll restore it since this is disabled by default now |
The general case was failing because Other case I noticed was pipeline code mirror, same workaround fixes that. |
One plugin left failing atm: Will see if patchable otherwise will restore the run every second hack I guess |
All is passing now in ATH, @jtnord can you take a look please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Tim, this looks like a great improvement.
Would like a review by @Vlatombe before this merges - as the enabling via system property may cause some issues for some of our testing.
public class FormElementPathPageDecorator extends PageDecorator { | ||
|
||
@SuppressFBWarnings("MS_SHOULD_BE_FINAL") | ||
private static /*almost final */ boolean ENABLED = Main.isUnitTest || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should still be able to flip this switch via the installation of a plugin?
Currently we spin up some Jenkins' instance where we do not configure system properties (or doing so is hard) and the current flow is to install the form-element-path
plugin without the use of the paths it provides. (e.g. auto provisioning in kubernetes)
@Vlatombe knows more about this area of the framework that we use internally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine, we'll be able to provide the system property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could also make it public as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as Vincent is ok with being able to provide it, we can keep it as it is for now (easier to open up, than restrict accesses later)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to turn this off by default, even in tests, at least until it can be rewritten to not rely on DOM listeners: jenkinsci/bom#746 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah that’s a shames :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⇒ #6004
|
||
@SuppressFBWarnings("MS_SHOULD_BE_FINAL") | ||
private static /*almost final */ boolean ENABLED = Main.isUnitTest || | ||
SystemProperties.getBoolean(FormElementPathPageDecorator.class.getName() + ".enabled"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
possible future enhancement would be to also set this for RealJenkinsRule
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should set isUnitTest
IIRC.
} | ||
|
||
/* JavaScript sometimes re-arranges the DOM and doesn't call layout callback | ||
* known cases: YUI buttons, CodeMirror. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhhh!!!! I wonder if this may well explain some issues we have with codemirror sections not being found in the ATH!
@jglick your comments should be addressed now if you want to take another look |
or @Vlatombe you able to approve? |
This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback. Thanks! |
PR to form-element-path to kill it off: jenkinsci/form-element-path-plugin#12 |
Example using form element path to make an HtmlUnit test more stable / easier to maintain: This test broke every time markup was touched a little bit |
See jenkinsci/form-element-path-plugin#11 (comment)
This inlines form-element-path so that we can change it as part of UI re-work without having to update a separate test tool and get it released. It will also enable htmlunit testing with more stable selectors which will be nice.
It is enabled by:
jenkins.formelementpath.FormElementPathPageDecorator.enabled=true *setting
jenkins.formelementpath.FormElementPathPageDecorator.ENABLED = true` via script console.ATH is setting system property with jenkinsci/acceptance-test-harness#712, all ATH tests are passing with this.
Plugin is EOLed in jenkinsci/form-element-path-plugin#12
For anyone who don't know what this is it's a plugin that provides an attribute on the DOM which is based on the 'path' to an attribute:
Proposed changelog entries
Proposed upgrade guidelines
N/A
Submitter checklist
Proposed changelog entries
section only if there are breaking changes or other changes which may require extra steps from users during the upgradeDesired reviewers
@mention
Maintainer checklist
Before the changes are marked as
ready-for-merge
:Proposed changelog entries
are correctupgrade-guide-needed
label is set and there is aProposed upgrade guidelines
section in the PR title. (example)lts-candidate
to be considered (see query).