-
Bug
-
Resolution: Won't Fix
-
Minor
-
2.285
Ever since 2.285, all the labels on the Configure UI have become centered thanks to the presence of the text-align: center attribute on the <body> tag that was not there in 2.284. See the attached images for how this looks in 284 vs 285, and note that it's still an issue in 296.
[JENKINS-65790] Configure UI labels are all centered
Paul Bienick
added a comment - miglen no, unfortunately, not yet. I just tried to update all the plugins and then Jenkins itself to 2.298 but the problem persists, so we are stuck on 2.284. What's odd is that the configure page initially displays correctly, and then suddenly everything becomes centered and all messed up. I will have to try selectively disable some plugins to see if one them is causing it.
Paul Bienick
added a comment - miglen no, unfortunately, not yet. I just tried to update all the plugins and then Jenkins itself to 2.298 but the problem persists, so we are stuck on 2.284. What's odd is that the configure page initially displays correctly, and then suddenly everything becomes centered and all messed up. I will have to try selectively disable some plugins to see if one them is causing it. Alright, so as it seems Jenkins has moved to default POST in the callback setting checkmethod as instead of GET. What does that mean is when you load the configure UI page each plugin has a callback to its own page to obtain additional information for the UI such as validation or contents for dropdowns. Since some plugins are outdated and or don't support POST methods at all the response is failing with 404 which breaks the UI. That doesn't mean that the overall functionality of the plugin is broken, but it seems that it was a bad assumption that led to backward compatibility. The move seems to be related to efforts in relation to CSRF protection.]
I don't expect an easy fix from Jenkins here and you have a couple of options:
1. Fork and update each plugin that suffers from this issue. You could use developer tools for example while the page is loading to find which /checkSomething pages are broken with 404.
2. Put a proxy with redirect certain queries to the backend from POST to GET
3. Wait for a general fix, which I don't expect anytime soon.
I hope that helps!
Miglen
added a comment - - edited Alright, so as it seems Jenkins has moved to default POST in the callback setting checkmethod as instead of GET . What does that mean is when you load the configure UI page each plugin has a callback to its own page to obtain additional information for the UI such as validation or contents for dropdowns. Since some plugins are outdated and or don't support POST methods at all the response is failing with 404 which breaks the UI. That doesn't mean that the overall functionality of the plugin is broken, but it seems that it was a bad assumption that led to backward compatibility. The move seems to be related to efforts in relation to CSRF protection .]
I don't expect an easy fix from Jenkins here and you have a couple of options:
1. Fork and update each plugin that suffers from this issue. You could use developer tools for example while the page is loading to find which /checkSomething pages are broken with 404.
2. Put a proxy with redirect certain queries to the backend from POST to GET
3. Wait for a general fix, which I don't expect anytime soon.
I hope that helps! Can you provide a list of plugins you are using? I've never seen this before...
Please use the script on:
https://www.jenkins.io/participate/report-issue/#Howtoreportanissue-WhatinformationtoprovideforEnvironmentandDescription
Miglen
added a comment - Hey timja in our case we use pyenv and rbenv plugins. You can see from their source that the no checkmethod is specified, therefore overwritten with POST by default which is not supported by the plugins.
Miglen
added a comment - Hey timja in our case we use pyenv and rbenv plugins. You can see from their source that the no checkmethod is specified, therefore overwritten with POST by default which is not supported by the plugins. I would recommend looking for alternatives, those plugins are due to be deprecated and removed 'soon'
https://groups.google.com/g/jenkinsci-dev/c/Ve0fqAud3Mk/m/MTIxw6ZyBwAJ
Interesting, these plugins seem to use an idiom specific to the Ruby Runtime syntax that requires GET by default:
Paul Bienick
added a comment - miglen - disabling the rbenv plugin fixed the issue. Thank you VERY MUCH for your help!
Paul Bienick
added a comment - miglen - disabling the rbenv plugin fixed the issue. Thank you VERY MUCH for your help! Paul Bienick
added a comment - This issue was resolved by disabling the rbenv plugin. 
Basil Crow
added a comment - Is anyone able to reproduce this issue on the latest weekly without any deprecated plugins installed? If this issue can still be reproduced on the latest weekly without any deprecated plugins installed, then it remains valid. If this issue cannot be reproduced on the latest weekly without any deprecated plugins installed, then in approximately a week I plan to close it as "Cannot Reproduce".
Basil Crow
added a comment - Is anyone able to reproduce this issue on the latest weekly without any deprecated plugins installed? If this issue can still be reproduced on the latest weekly without any deprecated plugins installed, then it remains valid. If this issue cannot be reproduced on the latest weekly without any deprecated plugins installed, then in approximately a week I plan to close it as "Cannot Reproduce". 
Hey pbenz have you managed to find a solution? We had identified that potentially this is related to how the Jenkins engine handles 404, specifically in our case it was related to the use of outdated and broken plugins such as pyenv and rubyenv.