Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-53462

Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • classic login form (before 2.128), regular "Save" form submission buttons on the classic UI
    • Jenkins 2.173 to 2.201, removed from 2.202, 2.289 released Apr 20, 2021

      HTML spec [[1]|https://w3c.github.io/uievents/#trusted-events] says "Most untrusted events will not trigger default actions, with the exception of the click event.". Now Firefox doesn't comply with the spec. When I try to fix the bug [[2]|https://bugzilla.mozilla.org/show_bug.cgi?id=1370630], a regression has happened on all Jenkins websites. Users can't login Jenkins websites with Firefox anymore. After some experiments, it seems the Jenkins websites detect the browser's user agent and use untrusted 'submit' event to start form submission when the current browser is Firefox. Changing the UA of Chrome to the same string as Firefox also block the form submission.

       

      The steps I used to reproduce this problem

      On Chrome

      1. Change UA to the same string as Firefox
      2. Navigate https://jenkins.qa.ubuntu.com/
      3. Click login
      4. Enter username/password and press 'log in' button
      5. Nothing happened

      Expectation

      Don't use untrusted events to start form submission on Jenkins websites.

       

      [1] https://w3c.github.io/uievents/#trusted-events

      [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1370630

       

          [JENKINS-53462] Jenkins websites use non-trusted 'submit' event to start form submission when current browser is Firefox

          Daniel Beck added a comment -

          Jenkins PR build for download at https://ci.jenkins.io/job/Core/job/jenkins/job/PR-3689/2/artifact/org/jenkins-ci/main/jenkins-war/2.147-rc27437.1590be3ff083/jenkins-war-2.147-rc27437.1590be3ff083.war

          Perhaps those watchers with ability to patch and build their own Firefox could check whether form submission buttons in this Jenkins build address the problem?

           

          Daniel Beck added a comment - Jenkins PR build for download at https://ci.jenkins.io/job/Core/job/jenkins/job/PR-3689/2/artifact/org/jenkins-ci/main/jenkins-war/2.147-rc27437.1590be3ff083/jenkins-war-2.147-rc27437.1590be3ff083.war Perhaps those watchers with ability to patch and build their own Firefox could check whether form submission buttons in this Jenkins build address the problem?  

          Henrik Skupin added a comment -

          Thanks danielbeck. Sadly I don't have a chance to run such a Jenkins build locally and verify all the different occurrences of this problem. You and tscherler should have the better overview of what to test.

          Therefore you wouldn't have to build Firefox with the patch but as I mentioned above just pick one of the older Firefox Nightly builds for your platform. The one which had this patch included can be found at https://archive.mozilla.org/pub/firefox/nightly/2017/07/2017-07-07-10-01-38-mozilla-central/.

           

          Let me know if that works for you. Thanks in advance!

          Henrik Skupin added a comment - Thanks danielbeck . Sadly I don't have a chance to run such a Jenkins build locally and verify all the different occurrences of this problem. You and tscherler should have the better overview of what to test. Therefore you wouldn't have to build Firefox with the patch but as I mentioned above just pick one of the older Firefox Nightly builds for your platform. The one which had this patch included can be found at https://archive.mozilla.org/pub/firefox/nightly/2017/07/2017-07-07-10-01-38-mozilla-central/.   Let me know if that works for you. Thanks in advance!

          Henrik Skupin added a comment -

          Henrik Skupin added a comment - Here the direct links to the builds: https://archive.mozilla.org/pub/firefox/nightly/2017/07/2017-07-07-10-01-38-mozilla-central/firefox-56.0a1.en-US.linux-i686.tar.bz2 https://archive.mozilla.org/pub/firefox/nightly/2017/07/2017-07-07-10-01-38-mozilla-central/firefox-56.0a1.en-US.linux-x86_64.tar.bz2   If you have another platform than Linux please let me know and I have to find the Windows and MacOS builds.

          Thorsten Scherler added a comment - - edited

          Thorsten Scherler added a comment - - edited whimboo https://youtu.be/o6bw5KEIqik AFAIC tell it works and debug mode: https://youtu.be/321YMNNozcE

          Henrik Skupin added a comment -

          tscherler, I assume that without your patch saving the settings doesn't work? Also AFAIR it was mentioned that all submit buttons throughout Jenkins are affected by that. They all work that way now? If yes, that sounds great.

          Henrik Skupin added a comment - tscherler , I assume that without your patch saving the settings doesn't work? Also AFAIR it was mentioned that all submit buttons throughout Jenkins are affected by that. They all work that way now? If yes, that sounds great.

          https://youtu.be/oT7orP-FdMs I just tested on master whimboo and it shows the issue description. I am pretty confident that the PR fixes the issue (not by winning a beauty competition, but...)

          Thorsten Scherler added a comment - https://youtu.be/oT7orP-FdMs I just tested on master whimboo and it shows the issue description. I am pretty confident that the PR fixes the issue (not by winning a beauty competition, but...)

          Henrik Skupin added a comment -

          Wonderful. In that case I assume you want to finish up the patch now? Is there something else you would need help with?

          My remaining question would be if we could also get this into a LTS release once it landed on master.

           

          Henrik Skupin added a comment - Wonderful. In that case I assume you want to finish up the patch now? Is there something else you would need help with? My remaining question would be if we could also get this into a LTS release once it landed on master.  

          Thorsten Scherler added a comment - - edited

          to your last question I guess danielbeck or rtyler can make this happen.

          The patch just needs some approves and it is done.

          BTW I just verified that other parts of jenkins will work as expected and I left a comment in the FF bugzilla to link to the pr as fix when people run into the issue on older versions of jenkins.

          HTH and thanks for all your hard work at mozilla!!!

          Thorsten Scherler added a comment - - edited to your last question I guess danielbeck or rtyler can make this happen. The patch just needs some approves and it is done. BTW I just verified that other parts of jenkins will work as expected and I left a comment in the FF bugzilla to link to the pr as fix when people run into the issue on older versions of jenkins. HTH and thanks for all your hard work at mozilla!!!

          Thorsten Scherler added a comment - - edited

          As final explanation why FF stopped working is that since we did not provide a callback to the onClick, FF correctly stops propagating and all other browser are wrong to propagate the event to a submit.

          We fixed the f:submit however the problem may occur in other parts but the solution will always be to provide a default fallback for onClick.

          Thorsten Scherler added a comment - - edited As final explanation why FF stopped working is that since we did not provide a callback to the onClick, FF correctly stops propagating and all other browser are wrong to propagate the event to a submit. We fixed the f:submit however the problem may occur in other parts but the solution will always be to provide a default fallback for onClick.

          Daniel Beck added a comment -

          My remaining question would be if we could also get this into a LTS release once it landed on master.

          Doubtful, the RC for the next LTS is due next Wednesday and we generally require changes to soak for at least two releases (~10 days), preferably three, before backporting.

          Should be in the early December LTS though.

          Daniel Beck added a comment - My remaining question would be if we could also get this into a LTS release once it landed on master. Doubtful, the RC for the next LTS is due next Wednesday and we generally require changes to soak for at least two releases (~10 days), preferably three, before backporting. Should be in the early December LTS though.

          Henrik Skupin added a comment -

          That's great to hear that you are considering it for a LTS release even it's not the upcoming one. Thanks a lot!

          Henrik Skupin added a comment - That's great to hear that you are considering it for a LTS release even it's not the upcoming one. Thanks a lot!

          Henrik Skupin added a comment -

          danielbeck, I simply want to report back that one of our engineers who works a lot with Jenkins just checked the latest release of Jenkins and it indeed seems to work all fine. Having it in the next LTS release would be fantastic! Thanks!

          Henrik Skupin added a comment - danielbeck , I simply want to report back that one of our engineers who works a lot with Jenkins just checked the latest release of Jenkins and it indeed seems to work all fine. Having it in the next LTS release would be fantastic! Thanks!

          Daniel Beck added a comment -

          We identified regressions that we believe are caused by this change (linked issues). This increases the likelihood that we won't choose 2.148 or newer as the next LTS baseline.

          Daniel Beck added a comment - We identified regressions that we believe are caused by this change (linked issues). This increases the likelihood that we won't choose 2.148 or newer as the next LTS baseline.

          Henrik Skupin added a comment -

          What I wonder is that the change here should have only affected Firefox, right? But people are filing issues for Chrome and IE.

          Henrik Skupin added a comment - What I wonder is that the change here should have only affected Firefox, right? But people are filing issues for Chrome and IE.

          Daniel Beck added a comment -

          Daniel Beck added a comment - https://github.com/jenkinsci/jenkins/pull/3689/files is more general than that.

          Henrik Skupin added a comment -

          Oh, I thought that this issue was about a custom behavior only used for Firefox; as stated in the issue summary. So the non-trusted `submit` event was used for all browsers then?

          Henrik Skupin added a comment - Oh, I thought that this issue was about a custom behavior only used for Firefox; as stated in the issue summary. So the non-trusted `submit` event was used for all browsers then?

          Jesse Glick added a comment -

          JENKINS-54233 was recently reported, though I cannot reproduce it and it does not seem to have anything to do with clicking buttons (though it does look like a JavaScript issue).

          Jesse Glick added a comment - JENKINS-54233 was recently reported, though I cannot reproduce it and it does not seem to have anything to do with clicking buttons (though it does look like a JavaScript issue).

          Daniel Beck added a comment - - edited

          Proposed reversal of the fix in https://github.com/jenkinsci/jenkins/pull/3760 due to regressions it caused (especially for the upcoming 2.150.x LTS line).

          Proposed amendment of the fix in https://github.com/jenkinsci/jenkins/pull/3761 in the hopes it would solve the problem. Due to time constraints this has undergone minimal testing, would appreciate if others could take a look.
          https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.152-rc27510.acc4eec688a0/ has the jenkins.war for this PR, which currently is 2.151 + the specific change.

          Daniel Beck added a comment - - edited Proposed reversal of the fix in https://github.com/jenkinsci/jenkins/pull/3760 due to regressions it caused (especially for the upcoming 2.150.x LTS line). Proposed amendment of the fix in https://github.com/jenkinsci/jenkins/pull/3761 in the hopes it would solve the problem. Due to time constraints this has undergone minimal testing, would appreciate if others could take a look. https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.152-rc27510.acc4eec688a0/ has the jenkins.war for this PR, which currently is 2.151 + the specific change.

          Henrik Skupin added a comment -

          Thank you for the update Daniel! I also asked on https://bugzilla.mozilla.org/show_bug.cgi?id=1399783 if someone could help testing it with Firefox. Hope the new proposed fix will be less regression-prone and will fix it.

          Henrik Skupin added a comment - Thank you for the update Daniel! I also asked on  https://bugzilla.mozilla.org/show_bug.cgi?id=1399783 if someone could help testing it with Firefox. Hope the new proposed fix will be less regression-prone and will fix it.

          Daniel Beck added a comment -

          Next attempt at fixing this is done towards the next weekly release, 2.173.

          Daniel Beck added a comment - Next attempt at fixing this is done towards the next weekly release, 2.173.

          Henrik Skupin added a comment -

          Thanks danielbeck! These are great news. I cannot await to see this being shipped with that release, and for a LTS later. Is there a place I can watch in which LTS release it will be included if stable?

          Henrik Skupin added a comment - Thanks danielbeck ! These are great news. I cannot await to see this being shipped with that release, and for a LTS later. Is there a place I can watch in which LTS release it will be included if stable?

          Daniel Beck added a comment -

          2.164.3, scheduled for May 8, the earliest, if accepted as a backport. The next .1, scheduled for early June, otherwise. Assuming of course we don't cause regressions again.

          Daniel Beck added a comment - 2.164.3, scheduled for May 8, the earliest, if accepted as a backport. The next .1, scheduled for early June, otherwise. Assuming of course we don't cause regressions again.

          Daniel Beck added a comment -

          FWIW if someone wants to test this with a patched Firefox build, docker run -p 8080:8080 jenkins/jenkins:2.173 and then go to http://localhost:8080 – should be fairly straightforward to get through the wizard, then e.g. Manage Jenkins » Configure System to go to a form with a formerly broken submit button ("Save").

          Daniel Beck added a comment - FWIW if someone wants to test this with a patched Firefox build, docker run -p 8080:8080 jenkins/jenkins:2.173 and then go to http://localhost:8080 – should be fairly straightforward to get through the wizard, then e.g. Manage Jenkins » Configure System to go to a form with a formerly broken submit button ("Save").

          Henrik Skupin added a comment -

          I won't have the time for testing it, but I requested a new Firefox build with the patch on https://bugzilla.mozilla.org/show_bug.cgi?id=1370630 applied. Currently the patch doesn't apply anymore. Once we have a build I will happily post a link to it.

          Henrik Skupin added a comment - I won't have the time for testing it, but I requested a new Firefox build with the patch on https://bugzilla.mozilla.org/show_bug.cgi?id=1370630 applied. Currently the patch doesn't apply anymore. Once we have a build I will happily post a link to it.

          Can someone verify the patch? I have failed to reproduce the problem using firefox-nightly-68.0a1.20190422-1 and jenkins/jenkins:2.172. Both logging in as admin and saving global config page works for me.

          Oliver Gondža added a comment - Can someone verify the patch? I have failed to reproduce the problem using firefox-nightly-68.0a1.20190422-1 and jenkins/jenkins:2.172 . Both logging in as admin and saving global config page works for me.

          Henrik Skupin added a comment -

          olivergondza, a normal nightly build of Firefox won't work given that it hasn't the patch from bug 1370630 included. You can pick a build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=3f12e17b558a36ef5b65235d663c4e617c3d328e&searchStr=build by just clicking the `B` symbol of your platform, selecting Job Details in the lower pane, and then `target.zip`, `target.dmg`, or `target.tar.bz2`. Just extract the archive and run the binary. With such a build you should be able to see the failure without the patch in Jenkins.

          Henrik Skupin added a comment - olivergondza , a normal nightly build of Firefox won't work given that it hasn't the patch from bug 1370630 included. You can pick a build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=3f12e17b558a36ef5b65235d663c4e617c3d328e&searchStr=build by just clicking the `B` symbol of your platform, selecting Job Details in the lower pane, and then `target.zip`, `target.dmg`, or `target.tar.bz2`. Just extract the archive and run the binary. With such a build you should be able to see the failure without the patch in Jenkins.

          Daniel Beck added a comment -

          olivergondza AFAIUI, the behavior of Chrome is the correct one (i.e. future Firefox's), so you should be able to confirm using Chrome with a Firefox user agent string. That's how I reproduced it and worked on the fix.

          Daniel Beck added a comment - olivergondza AFAIUI, the behavior of Chrome is the correct one (i.e. future Firefox's), so you should be able to confirm using Chrome with a Firefox user agent string. That's how I reproduced it and worked on the fix.

          Daniel Beck added a comment -

          whimboo Thanks for the link. "Save" buttons don't work on the nightly build and Jenkins 2.164.2, as expected. And they work on Jenkins 2.174, also as expected

          Daniel Beck added a comment - whimboo Thanks for the link. "Save" buttons don't work on the nightly build and Jenkins 2.164.2, as expected. And they work on Jenkins 2.174, also as expected

          Henrik Skupin added a comment -

          Great to be helpful. And that sounds fantastic. So we now have to wait for the 2.174 and an upcoming LTS before we can make that change live in Firefox.

          Henrik Skupin added a comment - Great to be helpful. And that sounds fantastic. So we now have to wait for the 2.174 and an upcoming LTS before we can make that change live in Firefox.

          Oliver Gondža added a comment - - edited

          Cool, thanks! I am backporting this to 2.164.3 to be released 2019-04-08 (EDIT: 2019-05-08), unless further regressions are found.

          whimboo, I do appreciate the effort put in making sure Jenkins is ready for the fix in Firefox. Though I am wondering if there is a chance to postpone the delivery until significant Jenkins (or what other applications are affected) userbase migrate to the fixed version.

          Oliver Gondža added a comment - - edited Cool, thanks! I am backporting this to 2.164.3 to be released 2019-04-08 (EDIT: 2019-05-08), unless further regressions are found. whimboo , I do appreciate the effort put in making sure Jenkins is ready for the fix in Firefox. Though I am wondering if there is a chance to postpone the delivery until significant Jenkins (or what other applications are affected) userbase migrate to the fixed version.

          Henrik Skupin added a comment -

          I assume you mean 2019-05-08.

          We can post-pone for sure. It's not that this patch is critical, and we already waited a while for it. Do you have some stats in how long it takes for the majority of users to upgrade to the next LTS release? Will it be one week, or two? Also note that the fix will land on mozilla-central only, which means it will only be part of a nightly build. Those people are tech-aware and should upgrade their instances fast enough.

           

          Our next merge to beta is on 2019-05-13, so I would suggest to at least wait until 2019-05-14 before landing that change in Firefox Nightly (69).

          Henrik Skupin added a comment - I assume you mean 2019-05-08. We can post-pone for sure. It's not that this patch is critical, and we already waited a while for it. Do you have some stats in how long it takes for the majority of users to upgrade to the next LTS release? Will it be one week, or two? Also note that the fix will land on mozilla-central only, which means it will only be part of a nightly build. Those people are tech-aware and should upgrade their instances fast enough.   Our next merge to beta is on 2019-05-13, so I would suggest to at least wait until 2019-05-14 before landing that change in Firefox Nightly (69).

          Daniel Beck added a comment -

          whimboo We are unfamiliar with the Firefox release schedule, could you clarify what that means in terms of rolling out the change to regular users? Those who are on 66.0.3 right now?

          For Jenkins, based on usage statistics, 60% of LTS users are within the last 4 LTS releases (~4 months), and 50% of weekly release users are within the last 16 releases (~3.5 months). So I expect the majority of Jenkins users to be on compatible releases around August/September, and they can update no later than May (for LTS), and should already be updated (for weekly releases).

          From a project POV, we only consider the latest LTS and weekly releases (e.g. only those get security fixes) to be supported. Of course users may lag behind in updating, and for some setups, updating Jenkins is a big project. The question the Firefox team will need to answer is, how aggressively do they want to annoy Firefox+Jenkins users that update one but not the other.

          Daniel Beck added a comment - whimboo We are unfamiliar with the Firefox release schedule, could you clarify what that means in terms of rolling out the change to regular users? Those who are on 66.0.3 right now? For Jenkins, based on usage statistics, 60% of LTS users are within the last 4 LTS releases (~4 months), and 50% of weekly release users are within the last 16 releases (~3.5 months). So I expect the majority of Jenkins users to be on compatible releases around August/September, and they can update no later than May (for LTS), and should already be updated (for weekly releases). From a project POV, we only consider the latest LTS and weekly releases (e.g. only those get security fixes) to be supported. Of course users may lag behind in updating, and for some setups, updating Jenkins is a big project. The question the Firefox team will need to answer is, how aggressively do they want to annoy Firefox+Jenkins users that update one but not the other.

          Henrik Skupin added a comment -

          danielbeck thank you for bringing this up. It's actually not my job to make such a decision, so I will leave it up to the release managers to decide. I will clearly reference your last comment, so that they are aware of the situation for Jenkins users.

           

          Henrik Skupin added a comment - danielbeck thank you for bringing this up. It's actually not my job to make such a decision, so I will leave it up to the release managers to decide. I will clearly reference your last comment, so that they are aware of the situation for Jenkins users.  

          Henrik Skupin added a comment - - edited

          Ok, so here an update. If that patch sticks and will not be backed out again, we will land the Firefox patch for Firefox 69 on May 14th or 15th. Which means it will ride the trains through beta, and will finally be released on Sep 3rd. If by that time there are still users who running a Jenkins LTS release earlier than 2.164.3, they will have to use Firefox 68 ESR. That ESR version will be maintained for another year, and will never have this patch included. Details see https://bugzilla.mozilla.org/show_bug.cgi?id=1370630#c41 and following.

           

          Thanks a lot again for the patch! It will unblock us from landing several features which are all blocked by this particular issue.

          Henrik Skupin added a comment - - edited Ok, so here an update. If that patch sticks and will not be backed out again, we will land the Firefox patch for Firefox 69 on May 14th or 15th. Which means it will ride the trains through beta, and will finally be released on Sep 3rd. If by that time there are still users who running a Jenkins LTS release earlier than 2.164.3, they will have to use Firefox 68 ESR. That ESR version will be maintained for another year, and will never have this patch included. Details see https://bugzilla.mozilla.org/show_bug.cgi?id=1370630#c41 and following.   Thanks a lot again for the patch! It will unblock us from landing several features which are all blocked by this particular issue.

          Daniel Beck added a comment -

          Reopened because 2.202 backed out the change again due to the regression it caused (JENKINS-58296).

          Daniel Beck added a comment - Reopened because 2.202 backed out the change again due to the regression it caused ( JENKINS-58296 ).

          Henrik Skupin added a comment -

          Hi danielbeck. After a year has been passed-by I wanted to check back if there has been made some progress on this particular issue. As known the change got backed out for 2.202, but was there any attempt again to get a fix landed?

          On our side we would kinda like to remove this broken code from Firefox but are still blocked by this particular web-compat issue.

          Thanks.

          Henrik Skupin added a comment - Hi danielbeck . After a year has been passed-by I wanted to check back if there has been made some progress on this particular issue. As known the change got backed out for 2.202, but was there any attempt again to get a fix landed? On our side we would kinda like to remove this broken code from Firefox but are still blocked by this particular web-compat issue. Thanks.

          Daniel Beck added a comment -

          I'm confused, according to https://issues.jenkins-ci.org/browse/JENKINS-58296?focusedCommentId=376769&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-376769 the Firefox change was backed out again, so I thought you'd given up on this.

          Daniel Beck added a comment - I'm confused, according to https://issues.jenkins-ci.org/browse/JENKINS-58296?focusedCommentId=376769&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-376769 the Firefox change was backed out again, so I thought you'd given up on this.

          Henrik Skupin added a comment -

          You are right, sorry. I will try to get a clarification from our DOM folks. I will report back when there are news.

          Henrik Skupin added a comment - You are right, sorry. I will try to get a clarification from our DOM folks. I will report back when there are news.

          Henrik Skupin added a comment -

          Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1370630#c72 for a possible strategy on our side. There is no ETA yet.

          Henrik Skupin added a comment - Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1370630#c72 for a possible strategy on our side. There is no ETA yet.

          Henrik Skupin added a comment -

          danielbeck, I would like to give a brief update. With Firefox 87 we shipped a fix for that behind the Firefox preference `dom.forms.submit.trusted_event_only`. By default this preference is `false`. And there is also a deprecation warning to indicate that untrusted submit events will be removed in a future release.

          Would that help Jenkins to fix the remaining issues, and get prepared for the official switch in Firefox at some point?

          Henrik Skupin added a comment - danielbeck , I would like to give a brief update. With Firefox 87 we shipped a fix for that behind the Firefox preference ` dom.forms.submit.trusted_event_only `. By default this preference is `false`. And there is also a deprecation warning to indicate that untrusted submit events will be removed in a future release. Would that help Jenkins to fix the remaining issues, and get prepared for the official switch in Firefox at some point?

          Daniel Beck added a comment -

          whimboo Thanks for letting us know!

          Form submission via untrusted submit event is deprecated and will be removed at a future date.

          Just tried this. Nice

          Would that help Jenkins to fix the remaining issues, and get prepared for the official switch in Firefox at some point?

          I would have to look into what the current status is, but I think the previous fix caused problems with file uploads for us; those forms ended up submitted twice. The fix for that was reverting my earlier change

          I'm not sure I understand the space well enough to fix it myself, but now that we're on notice, I hope we'll be able to get someone to look into this.

          Daniel Beck added a comment - whimboo Thanks for letting us know! Form submission via untrusted submit event is deprecated and will be removed at a future date. Just tried this. Nice Would that help Jenkins to fix the remaining issues, and get prepared for the official switch in Firefox at some point? I would have to look into what the current status is, but I think the previous fix caused problems with file uploads for us; those forms ended up submitted twice. The fix for that was reverting my earlier change I'm not sure I understand the space well enough to fix it myself, but now that we're on notice, I hope we'll be able to get someone to look into this.

          Henrik Skupin added a comment -

           Great. Let me know if you see any problems. At least being able to turn on/off the feature should hopefully help to make it work for both modes. If that's not possible we would still have to figure out a good release process for that feature once we are ready to ship it.

          Henrik Skupin added a comment -  Great. Let me know if you see any problems. At least being able to turn on/off the feature should hopefully help to make it work for both modes. If that's not possible we would still have to figure out a good release process for that feature once we are ready to ship it.

          Daniel Beck added a comment -

          Daniel Beck added a comment - Fix attempt at https://github.com/jenkinsci/jenkins/pull/5405

          Henrik Skupin added a comment -

          danielbeck I have seen that the PR on Github has been merged, which is great to see. What else is left on the Jenkins side, and what does it mean to this issue report? Can it be closed now?

          Which version including the LTS will contain this fix? Depending on the other issues that we have to fix what is the time frame of shipping this code? Thanks.

          Henrik Skupin added a comment - danielbeck I have seen that the PR on Github has been merged, which is great to see. What else is left on the Jenkins side, and what does it mean to this issue report? Can it be closed now? Which version including the LTS will contain this fix? Depending on the other issues that we have to fix what is the time frame of shipping this code? Thanks.

          Daniel Beck added a comment -

          Can it be closed now?

          We usually do that only once a weekly release is out that has the fix. Too many folks are otherwise confused ("I'm on the latest release and the bug is still there" etc).

          Which version including the LTS will contain this fix?

          TBD, whichever LTS line includes 2.289 (unless we have to back it out again ); we decide on baseline later this week. I doubt we want to expedite into LTS again after the problems last time.

          Depending on the other issues that we have to fix what is the time frame of shipping this code?

          Maybe in LTS early June, pretty sure in LTS late August.

          Daniel Beck added a comment - Can it be closed now? We usually do that only once a weekly release is out that has the fix. Too many folks are otherwise confused ("I'm on the latest release and the bug is still there" etc). Which version including the LTS will contain this fix? TBD, whichever LTS line includes 2.289 (unless we have to back it out again ); we decide on baseline later this week. I doubt we want to expedite into LTS again after the problems last time. Depending on the other issues that we have to fix what is the time frame of shipping this code? Maybe in LTS early June, pretty sure in LTS late August.

          Henrik Skupin added a comment -

          Thank you for the information! If there is a problem on our side please also let me know.

          Henrik Skupin added a comment - Thank you for the information! If there is a problem on our side please also let me know.

          Mark Waite added a comment -

          Jenkins 2.289 released Apr 20, 2021 included PR-5405

          Mark Waite added a comment - Jenkins 2.289 released Apr 20, 2021 included PR-5405

          Mark Waite added a comment -

          Change in Jenkins 2.289 seems to have caused a regression described in the pull request comment.

          Mark Waite added a comment - Change in Jenkins 2.289 seems to have caused a regression described in the pull request comment .

          Henrik Skupin added a comment -

          danielbeck, could you please give an update here? Given the last comment on this issue there is another regression. So far I haven't seen a backout, so does it mean your patch will be kept in the https://www.jenkins.io/changelog-stable/#v2.289.2 LTS release? Thanks!

          Henrik Skupin added a comment - danielbeck , could you please give an update here? Given the last comment on this issue there is another regression. So far I haven't seen a backout, so does it mean your patch will be kept in the https://www.jenkins.io/changelog-stable/#v2.289.2 LTS release? Thanks!

          Daniel Beck added a comment -

          whimboo Looks like we've reached a stable state after https://github.com/jenkinsci/jenkins/pull/5479

          Daniel Beck added a comment - whimboo Looks like we've reached a stable state after https://github.com/jenkinsci/jenkins/pull/5479

          Henrik Skupin added a comment -

          Thanks a lot for the confirmation!

          Henrik Skupin added a comment - Thanks a lot for the confirmation!

            Unassigned Unassigned
            iamstone ming-chou shih
            Votes:
            1 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: