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

          R. Tyler Croy added a comment -

          The WEBSITE project is for jenkins.io and those sorts of issues.

           

          That said, jenkins.qa.ubuntu.com is running a version of Jenkins more than two years old at this point.

          R. Tyler Croy added a comment - The WEBSITE project is for jenkins.io and those sorts of issues.   That said, jenkins.qa.ubuntu.com is running a version of Jenkins more than two years old at this point.

          My apologies if I ask some stupid questions. I'm wondering if the new version of Jenkins still uses untrusted 'submit' event? I tried to find out the steps to test it by myself but failed due to few understandings about it. I'm thinking about the possible solution to stop using untrusted submit event in Firefox without breaking too many existed websites. Any suggestions are very welcome. Thanks.

          ming-chou shih added a comment - My apologies if I ask some stupid questions. I'm wondering if the new version of Jenkins still uses untrusted 'submit' event? I tried to find out the steps to test it by myself but failed due to few understandings about it. I'm thinking about the possible solution to stop using untrusted submit event in Firefox without breaking too many existed websites. Any suggestions are very welcome. Thanks.

          Oleg Nenashev added a comment -

          FYI danielbeck, seems to be a security-related matter

          Oleg Nenashev added a comment - FYI danielbeck , seems to be a security-related matter

          Edgar Chen added a comment - - edited

          Hi, I could not reproduce this problem in the weekly version of Jenkins, but I still could reproduce it on LTS version. Should we reopen this issue for LTS version? Thank you.

          Edgar Chen added a comment - - edited Hi, I could not reproduce this problem in the weekly version of Jenkins, but I still could reproduce it on LTS version. Should we reopen this issue for LTS version? Thank you.

          Henrik Skupin added a comment - - edited

          There was a refactoring of the login page which may have changed this in version 2.128 from June 18th this year?

           

          Jira issue: https://issues.jenkins-ci.org/browse/JENKINS-50447

          Github PR: https://github.com/jenkinsci/jenkins/pull/3380

           

          Henrik Skupin added a comment - - edited There was a refactoring of the login page which may have changed this in version 2.128 from June 18th this year?   Jira issue: https://issues.jenkins-ci.org/browse/JENKINS-50447 Github PR: https://github.com/jenkinsci/jenkins/pull/3380  

          Henrik Skupin added a comment -

          oleg_nenashev, danielbeck, if the fix cannot be integrated in the current LTS release, is there already an ETA when the next major LTS release will happen? Thanks.

          Henrik Skupin added a comment - oleg_nenashev , danielbeck , if the fix cannot be integrated in the current LTS release, is there already an ETA when the next major LTS release will happen? Thanks.

          Daniel Beck added a comment -

          I cannot, and could never, despite Firefox being my default browser, reproduce the issue on any Jenkins instance, and it is unclear that the issue as reported actually exists in current releases of Jenkins. More information is needed before we even consider this to be an open bug.

          Daniel Beck added a comment - I cannot, and could never, despite Firefox being my default browser, reproduce the issue on any Jenkins instance, and it is unclear that the issue as reported actually exists in current releases of Jenkins. More information is needed before we even consider this to be an open bug.

          Daniel Beck added a comment -

          FWIW the next LTS to be released in a week is 2.138.1, and will include the new login page. If that addresses the problem for you, I suppose this is fixed?

          Daniel Beck added a comment - FWIW the next LTS to be released in a week is 2.138.1, and will include the new login page. If that addresses the problem for you, I suppose this is fixed?

          Henrik Skupin added a comment -

          Let me quickly summarize. There is a bug in Firefox which we want to get fixed. But that is not possible because with the patched version of Firefox a login it not possible anymore due to the usage of untrusted submit events.

           

          To actually reproduce the bug you cannot use a normal release of Firefox but it would have to be one from the "first release with" here: https://hg.mozilla.org/mozilla-central/rev/367b6f947f87.

           

          I'm fairly sure that waiting a week is totally fine if the above referenced fix in Jenkins is really the one which we need. It was just a speculation because I cannot test it myself.

          Henrik Skupin added a comment - Let me quickly summarize. There is a bug in Firefox which we want to get fixed. But that is not possible because with the patched version of Firefox a login it not possible anymore due to the usage of untrusted submit events.   To actually reproduce the bug you cannot use a normal release of Firefox but it would have to be one from the "first release with" here: https://hg.mozilla.org/mozilla-central/rev/367b6f947f87.   I'm fairly sure that waiting a week is totally fine if the above referenced fix in Jenkins is really the one which we need. It was just a speculation because I cannot test it myself.

          Daniel Beck added a comment -

          OK. The bug currently in Firefox allows the login to happen, which is why I never encountered the described problem. Once the bug in Firefox is fixed, it will no longer be able to use the login form. Now I got it.

          Would be interesting to know whether simply giving Firefox the 'Chrome behavior' (if any), i.e. modifying or removing browser detection, would make this work. That should be fairly straightforward, I hope.

          I'll move this to the correct Jira project.

          Daniel Beck added a comment - OK. The bug currently in Firefox allows the login to happen, which is why I never encountered the described problem. Once the bug in Firefox is fixed, it will no longer be able to use the login form. Now I got it. Would be interesting to know whether simply giving Firefox the 'Chrome behavior' (if any), i.e. modifying or removing browser detection, would make this work. That should be fairly straightforward, I hope. I'll move this to the correct Jira project.

          Daniel Beck added a comment -

          whimboo Can you clarify what release of Firefox this should be in? From my reading, it should be in 56.x, but I'm on 61, soon 62, and can log in just fine, current or previous login form.

          Daniel Beck added a comment - whimboo Can you clarify what release of Firefox this should be in? From my reading, it should be in 56.x, but I'm on 61, soon 62, and can log in just fine, current or previous login form.

          Henrik Skupin added a comment -

          We had to backout the patch due to the regression with Jenkins. As such it was only available in some Nightly builds of Firefox during the 56 development process.

          Henrik Skupin added a comment - We had to backout the patch due to the regression with Jenkins. As such it was only available in some Nightly builds of Firefox during the 56 development process.

          Henrik Skupin added a comment -

          Ok, so I checked with such a Nightly build and switched the user agent to Chrome. That actually fixed it, yes.

          Henrik Skupin added a comment - Ok, so I checked with such a Nightly build and switched the user agent to Chrome. That actually fixed it, yes.

          Daniel Beck added a comment -

          I wonder what happens with Jenkins in current releases of Firefox if we remove the special treatment. I assume that was added for a reason.

          IOW, do we rip out the Firefox special behavior, or do we need more elaborate Firefox special behavior to remain compatible with current and future Firefox.

          Daniel Beck added a comment - I wonder what happens with Jenkins in current releases of Firefox if we remove the special treatment. I assume that was added for a reason. IOW, do we rip out the Firefox special behavior, or do we need more elaborate Firefox special behavior to remain compatible with current and future Firefox.

          Edgar Chen added a comment -

          I checked the LTS 2.121.2 and 2.121.3, I still saw the Firefox special behavior. I am not sure if 2.138.1 fixes this, but I am happy to test again.

          From the form submission point of view, it is not necessary to give Firefox special behavior, giving the same behavior as other browser should just also work on Firefox.

          Edgar Chen added a comment - I checked the LTS 2.121.2 and 2.121.3, I still saw the Firefox special behavior. I am not sure if 2.138.1 fixes this, but I am happy to test again. From the form submission point of view, it is not necessary to give Firefox special behavior, giving the same behavior as other browser should just also work on Firefox.

          Daniel Beck added a comment -

          Should be testable by setting a different User-Agent on a prod release of Firefox I suppose.

          Daniel Beck added a comment - Should be testable by setting a different User-Agent on a prod release of Firefox I suppose.

          Daniel Beck added a comment -

          And assuming Chrome behaves to spec (like Firefox post-fix), we should be able to observe the problem in Jenkins by setting Chrome's User-Agent to Firefox.

          Daniel Beck added a comment - And assuming Chrome behaves to spec (like Firefox post-fix), we should be able to observe the problem in Jenkins by setting Chrome's User-Agent to Firefox.

          Edgar Chen added a comment -

          Or you can test this by setting User-Agent to Firefox on Chrome.

          Edgar Chen added a comment - Or you can test this by setting User-Agent to Firefox on Chrome.

          Daniel Beck added a comment -

          And assuming Chrome behaves to spec (like Firefox post-fix), we should be able to observe the problem in Jenkins by setting Chrome's User-Agent to Firefox.

          This is exactly what's happening.

          The good news is that the redesigned login form will work in 2.138.1.

          The bad news is that all other submit buttons will not. It's not quite as bad as before, as most forms have an 'Apply' button that still works, but close.

          Daniel Beck added a comment - And assuming Chrome behaves to spec (like Firefox post-fix), we should be able to observe the problem in Jenkins by setting Chrome's User-Agent to Firefox. This is exactly what's happening. The good news is that the redesigned login form will work in 2.138.1. The bad news is that all other submit buttons will not. It's not quite as bad as before, as most forms have an 'Apply' button that still works, but close.

          Henrik Skupin added a comment -

          Regarding the bad news, about how many different submit buttons we are talking here? Is it something which could easily be fixed and shipped, or how long would it take? So far Jenkins seems to be the only site which blocks us from shipping this feature fix, and we really would like to get this out to our users for a better web platform conformance.

           

          Thanks.

          Henrik Skupin added a comment - Regarding the bad news, about how many different submit buttons we are talking here? Is it something which could easily be fixed and shipped, or how long would it take? So far Jenkins seems to be the only site which blocks us from shipping this feature fix, and we really would like to get this out to our users for a better web platform conformance.   Thanks.

          Daniel Beck added a comment -

          I suspect it'll be one button, but it's reused a lot as the f:submit form control. Just needs someone to figure out where JS takes a wrong turn to address this.

          Daniel Beck added a comment - I suspect it'll be one button, but it's reused a lot as the  f:submit  form control. Just needs someone to figure out where JS takes a wrong turn to address this.

          I will have a look now whether I can come up with a fix.

          My understanding so far:

          • I need a patched FF version (the earlier links do not work anymore, can you whimboo provide me with a link?)
          • The "new login" page works, as danielbeck said, most likely because I only used vanilla js, no external libs and especially no
            f:submit
          • in the bugzilla thread someone mentioned YUI I think that may be the base problem.

          I will now review the

          f:submit

          and see whether I can extract all usage of YUI and do "vanilla js" submits.

          Thorsten Scherler added a comment - I will have a look now whether I can come up with a fix. My understanding so far: I need a patched FF version (the earlier links do not work anymore, can you whimboo provide me with a link?) The "new login" page works, as danielbeck said, most likely because I only used vanilla js, no external libs and especially no f:submit in the bugzilla thread someone mentioned YUI I think that may be the base problem. I will now review the f:submit and see whether I can extract all usage of YUI and do "vanilla js" submits.

          Daniel Beck added a comment -

          tscherler

          I need a patched FF version

          Not quite. All you need is a Chrome that claims to be FF, then that will encounter the same problem as patched/future Firefox would. Probably simpler to get started

          Daniel Beck added a comment - tscherler I need a patched FF version Not quite. All you need is a Chrome that claims to be FF, then that will encounter the same problem as patched/future Firefox would. Probably simpler to get started

          https://github.com/scherler/jenkins/tree/JENKINS-53462 I created a callback and in case we have a submit type we look up the parent form and submit it.

          ...I know but those 9 line of code is based on different approaches and to not break the universe I implemented like as-is.

          Thorsten Scherler added a comment - https://github.com/scherler/jenkins/tree/JENKINS-53462 I created a callback and in case we have a submit type we look up the parent form and submit it. ...I know but those 9 line of code is based on different approaches and to not break the universe I implemented like as-is.

          Thorsten Scherler added a comment - https://github.com/jenkinsci/jenkins/pull/3689 the hack version

          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.

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

              Created:
              Updated:
              Resolved: