Adding my comment from JRASERVER-74914

 Why is it acceptable to tell users that they should just resize their browser window or adjust the zoom in/out in order to fix the size of the transition pop up window? 

 Why is it acceptable to force users to develop a javascript hack to force a different size to the transition pop up window? 

There have been 47 releases for Jira 9 since June 2022, https://www.atlassian.com/software/jira/update.

This bug was clearly introduced in Jira 9 and is still clearly affecting all 9.x versions.

 Can we get an update? 

Related issues that I found:

• JRASERVER-74877
• JSDSERVER-12436
• JRASERVER-74827
• JRASERVER-76913
• JRASERVER-75602

@Christina Schlager

If you don't use the announcement banner to actually display text, those lines hide the skinny banner. If you want the banner to display, don't add those lines.

Hi c864ce9cd21f, 

Thank you for your workaround, it works great.

However, I wonder why this part is necessary and whether it can be skipped: 

<style>
    div#announcement-banner {
          display: none;
    }
</style> 

c864ce9cd21f,

Works, but there's a one downside not related to the last change – subsequent reloads from Search form causes the page loading slowdown.

Just enter some filter that returns a bunch of results in Search window using Detail view and click any issue multiple times (to reload the page). Each next load will slowdown. If this workaround is removed from Announcement Banner, it works fast as it should.

I think it's due to setTimeout trigger reflows and multiple timeouts are being set. Or maybe we should add

JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, function (e, context, reason) {
...
if (reason == JIRA.CONTENT_ADDED_REASON.dialogReady) {
...
}

additionally

Adding reason == JIRA.CONTENT_ADDED_REASON.dialogReady helps in my case.

Hi @Alexander

please check this script

<style>
div#announcement-banner {
              display: none;
}
</style>
<script>
document.addEventListener("DOMContentLoaded", () => {
    var isWindows = navigator.platform.toUpperCase().indexOf('WIN') !== -1;
             
    if(isWindows){
        JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, function () {
            for (var i in [100, 300, 500]) {
                setTimeout(function(){ adjustSize(); }, i);
            }
        });
    }
});
function adjustSize()
{
    var formSelector = " form div.form-body"; 
    var height = AJS.$(window).height();
    AJS.$("div[id='edit-comment']" + formSelector).css("max-height", height+"px");
    AJS.$("div[id^=workflow]" + formSelector).css("max-height", height+"px");
    AJS.$("div#link-issue-dialog" + formSelector).css("max-height", height+"px");
 
    if(typeof(Event) === 'function'){
        window.dispatchEvent(new Event('resize'));
    }else{
        var evt = window.document.createEvent('UIEvents');
        evt.initUIEvent('resize', true, false, window, 0);
        window.dispatchEvent(evt);
    }
}
</script>
 

Best Regards

Adam Labus

it.Lab Atlassian Marketplace

c864ce9cd21f,

Hi. Your workaround works great, but Edit Comment is affected too. JIRA 9.12.0 LTS. Can your workaround be implemented for it?

Hey Atlassian, unfortunately attachments are not allowed here, but it does not seem to be properly fixed in 9.12.

The transition screen is still a lot smaller than the Edit screen, for example.

.

Hello, solution:
"As a workaround, the browser can be minimized and maximized, or the browser window can be resized/moved. Then, the pop-up workflow issue screen will return to correct size. "

should I resize browser on every transition and action in Jira ?  

Thanks @Adam, works great! I wonder how many Jira admins were already saved by your script from user backlash, while this issue is still sitting on the "Long Term Backlog"...