[JENKINS-75727] RootActions with a jumplist lose functionality when collapsed

[jenkins-infra-bot]

If a RootAction defines a jumplist.jelly then when the header is collapsed the jumplist is lost and there is no way to access it.

Given the jumplist is the "new way" to replace l:tasks it is expected that this works (and is distinct from JENKINS-75683)

steps to reproduce

Create a new RootAction that implements a jump list and install the plugin into Jenkins.
ensure the screen is wide and the action is shown in the main header
Hover over the Action icon to verify the jumplist is show
Make the screen smaller (or install more plugins with RootActions so that the RootAction is moved to the overflow "..." menu
Hover over the RootAction in the overflow menu

Expected Results

The jumplist is shown (somehow) to the user

Actual Results

The jumplist is not shown.

Notes

in

jenkins/src/main/js/components/header/actions-overflow.js

Lines 40 to 67 in 6efa0db

	Utils.generateDropdown(
	overflowButton,
	(instance) => {
	const mappedItems = items.map((e) => {
	let icon = e.querySelector("img");
	if (icon) {
	icon = icon.src;
	}
	let iconXml = e.querySelector("svg");
	if (iconXml) {
	icon = true;
	iconXml = iconXml.outerHTML;
	}
	const span = e.querySelector("[data-type='action-label']");
	let label = e.textContent;
	if (span !== null) {
	label = span.textContent;
	}
	return {
	type: "link",
	icon: icon,
	iconXml: iconXml,
	label: label,
	url: e.href,
	};
	});

all fnctionality appears to be removed except for the text icon and link.

---

Originally reported by teilo, imported from: RootActions with a jumplist lose functionality when collapsed

• status: Open
• priority: Major
• component(s): core
• label(s): lts-candidate, ux
• resolution: Unresolved
• votes: 0
• watchers: 3
• imported: 2025-11-24

Raw content of original issue

If a RootAction defines a jumplist.jelly then when the header is collapsed the jumplist is lost and there is no way to access it.

Given the jumplist is the "new way" to replace l:tasks it is expected that this works (and is distinct from JENKINS-75683)

steps to reproduce

Create a new RootAction that implements a jump list and install the plugin into Jenkins.
ensure the screen is wide and the action is shown in the main header
Hover over the Action icon to verify the jumplist is show
Make the screen smaller (or install more plugins with RootActions so that the RootAction is moved to the overflow "..." menu
Hover over the RootAction in the overflow menu

Expected Results

The jumplist is shown (somehow) to the user

Actual Results

The jumplist is not shown.

Notes

in 

  

    

      jenkins/src/main/js/components/header/actions-overflow.js
    
    

        Lines 40 to 67
      in
      6efa0db
    
  
  

    


        

          

          
 Utils.generateDropdown( 
        

        

          

          
   overflowButton, 
        

        

          

          
   (instance) => { 
        

        

          

          
     const mappedItems = items.map((e) => { 
        

        

          

          
       let icon = e.querySelector("img"); 
        

        

          

          
       if (icon) { 
        

        

          

          
         icon = icon.src; 
        

        

          

          
       } 
        

        

          

          
       let iconXml = e.querySelector("svg"); 
        

        

          

          
       if (iconXml) { 
        

        

          

          
         icon = true; 
        

        

          

          
         iconXml = iconXml.outerHTML; 
        

        

          

          
       } 
        

        

          

          
  
        

        

          

          
       const span = e.querySelector("[data-type='action-label']"); 
        

        

          

          
       let label = e.textContent; 
        

        

          

          
       if (span !== null) { 
        

        

          

          
         label = span.textContent; 
        

        

          

          
       } 
        

        

          

          
  
        

        

          

          
       return { 
        

        

          

          
         type: "link", 
        

        

          

          
         icon: icon, 
        

        

          

          
         iconXml: iconXml, 
        

        

          

          
         label: label, 
        

        

          

          
         url: e.href, 
        

        

          

          
       }; 
        

        

          

          
     }); 
        
    
  

 all fnctionality appears to be removed except for the text icon and link.

• environment: Jenkins 2.507+

[jenkins-infra-bot]

• Remote link associated with this issue:

  • jenkinsci/jenkins#​10729

[jenkins-infra-bot]

teilo:

• Original comment link
• Raw content of original comment:

  PR that semi fixes this.
  the jumplist is still not shown when in the collapsed menu, but when it is the current page it is shown uncollapsed.
  As such, it will always have the jumplist shown
  

PR that semi fixes this.
the jumplist is still not shown when in the collapsed menu, but when it is the current page it is shown uncollapsed.
As such, it will always have the jumplist shown

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  teilo let me know if it was a mistake for me to close this.  I close issues that are listed as resolved in the weekly changelog, but am happy to reopen it if the implemented is not enough for you to be comfortable that the issue should be closed.
  

teilo let me know if it was a mistake for me to close this. I close issues that are listed as resolved in the weekly changelog, but am happy to reopen it if the implemented is not enough for you to be comfortable that the issue should be closed.

[jenkins-infra-bot]

teilo:

• Original comment link
• Raw content of original comment:

  markewaite So this is still an issue, what we have now is:  once you click on an action that is "collapsed" (ie is now in the hamburger) we move it out of the collapsed section so you can use its jumplists.
  
  but you need to make this action, there is no jumplist support inside the hamburger menu itself (which is the same as the collapsed menu, just now we collapse all non primary actions except the current action (if any))
  
  we can either keep this issue open or create a new issue describing the issue in the hamburger.
  

markewaite So this is still an issue, what we have now is: once you click on an action that is "collapsed" (ie is now in the hamburger) we move it out of the collapsed section so you can use its jumplists.

but you need to make this action, there is no jumplist support inside the hamburger menu itself (which is the same as the collapsed menu, just now we collapse all non primary actions except the current action (if any))

we can either keep this issue open or create a new issue describing the issue in the hamburger.

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  we can either keep this issue open or create a new issue describing the issue in the hamburger.
  
  Thanks.  I'll reopen this issue.
  

we can either keep this issue open or create a new issue describing the issue in the hamburger.

Thanks. I'll reopen this issue.

[jenkins-infra-bot]

atual:

• Original comment link
• Raw content of original comment:

  I don't know if it's the right place to comment on this but the source code led me to this ticket:
  
  This change breaks one of our features on the latest Jenkins (2.519 but started to break earlier) with our current plugin version:
  
  	
  This custom action is not shown in the left menu, only in the hamburger menu (took me a few hours to discover this)
  	
  As I understand it, it would be shown in the left menu if it implemented isPrimaryAction(), but it's a new method on the interface that we do not compile against (we want to depend on an older version at least for some time). If I still add it, it fails with an IllegalAccessException.
  
  
  
  Can you please clarify if this will be fixed, or will be kept as a breaking change ? In that case, we can just document this and fix our acceptance test accordingly.
  

I don't know if it's the right place to comment on this but the source code led me to this ticket:

This change breaks one of our features on the latest Jenkins (2.519 but started to break earlier) with our current plugin version:

• This custom action is not shown in the left menu, only in the hamburger menu (took me a few hours to discover this)
• As I understand it, it would be shown in the left menu if it implemented isPrimaryAction(), but it's a new method on the interface that we do not compile against (we want to depend on an older version at least for some time). If I still add it, it fails with an IllegalAccessException.

Can you please clarify if this will be fixed, or will be kept as a breaking change ? In that case, we can just document this and fix our acceptance test accordingly.

[jenkins-infra-bot]

teilo:

• Original comment link
• Raw content of original comment:

  you can implement the method without requiring a new version.
  
  That said - what makes this action so special that it should be considered a primary action?  Initially I thought it would only show if there where errors but I do not think that is the case based on a quick glance of the code.
  

you can implement the method without requiring a new version.

That said - what makes this action so special that it should be considered a primary action? Initially I thought it would only show if there where errors but I do not think that is the case based on a quick glance of the code.

[jenkins-infra-bot]

atual:

• Original comment link
• Raw content of original comment:

  you can implement the method without requiring a new version.
  I tried, keeping jenkins.version to 2.479.3, it fails at runtime on Jenkins 2.519 with:
  
  Caused by: java.lang.IllegalAccessError
  	at java.base/jdk.internal.misc.Unsafe.throwIllegalAccessError(Unsafe.java:3463)
  	at hudson.Functions.showInPrimaryHeader(Functions.java:2109)
  	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
  	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
  	at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258)
  	at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
  	at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
  	at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
  	at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
  	at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
  	at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:76)
  	at org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134)
  	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
  	at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
  	at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
  	at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:271)
  	... 88 more
  
  
  
  That said - what makes this action so special that it should be considered a primary action? Initially, I thought it would only show if there were errors, but I do not think that is the case based on a quick glance at the code.
  Indeed, as of now, it shows up all the time, we can reconsider this for newer Jenkins versions in light of this new primary action concept.
  

you can implement the method without requiring a new version.

I tried, keeping jenkins.version to 2.479.3, it fails at runtime on Jenkins 2.519 with:

Caused by: java.lang.IllegalAccessError
	at java.base/jdk.internal.misc.Unsafe.throwIllegalAccessError(Unsafe.java:3463)
	at hudson.Functions.showInPrimaryHeader(Functions.java:2109)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258)
	at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
	at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
	at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
	at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
	at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
	at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:76)
	at org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
	at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
	at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:271)
	... 88 more

That said - what makes this action so special that it should be considered a primary action? Initially, I thought it would only show if there were errors, but I do not think that is the case based on a quick glance at the code.

Indeed, as of now, it shows up all the time, we can reconsider this for newer Jenkins versions in light of this new primary action concept.

[jenkins-infra-bot]

teilo:

• Original comment link
• Raw content of original comment:

  
  I tried, keeping jenkins.version to 2.479.3, it fails at runtime on Jenkins 2.519 with:
  
  link to a PR?  what was the signature that you implemented?
  
  
  Indeed, as of now, it shows up all the time
  
  You also have `getBadge` which can be used to show an alert and a reason that will cause a badge to show on the hamburger to draw attention to an issue.
  

I tried, keeping jenkins.version to 2.479.3, it fails at runtime on Jenkins 2.519 with:

link to a PR? what was the signature that you implemented?

Indeed, as of now, it shows up all the time

You also have `getBadge` which can be used to show an alert and a reason that will cause a badge to show on the hamburger to draw attention to an issue.

[jenkins-infra-bot]

atual:

• Original comment link
• Raw content of original comment:

  Oh well, I forgot to make the method public... Now, it works fine by showing it at the top right, not on the left menu, though. So I guess there won't be any way to augment the left menu anymore, right?
  

Oh well, I forgot to make the method public... Now, it works fine by showing it at the top right, not on the left menu, though. So I guess there won't be any way to augment the left menu anymore, right?

[jenkins-infra-bot]

teilo:

• Original comment link
• Raw content of original comment:

  > there won't be any way to augment the left menu anymore
  
  I do not follow?  perhaps this is better suited to the dev mailing list now.
  

> there won't be any way to augment the left menu anymore

I do not follow? perhaps this is better suited to the dev mailing list now.