In Ondemand 3.1 when a user launched an app it started in a new browser tab. With the new 4.2.2. upgrade launching apps start in the same tab. How can I get back the old app in new tab action?
The change was made for accessibility purposes, so in general we wouldnāt recommend changing this. Even if a link opens in the same tab by default, an individual user can right click and decide to open in a new tab if they wish (the reverse is not true for links that open in new tabs). You should also make sure that you are not bound by any digital accessibility policies that would require that behavior.
That being said, there are customizations that allow you to change this. If your app is launched from the navbar, then you can modify your custom menu items to include the new_tab attribute. If your app is a batch connect app you can look at the view.html.erb (see Connection View ā Open OnDemand 4.2.0 documentation ) and modify the button html directly.
If neither of those apply then you can provide more details about the app in question and Iād be happy to look into it further.
You can also try adding the new_window attribute to the appās manifest.yml, which confusingly sets the new_tab attribute on the link, not actually opening a new window.
Hey Braeden,
I just updated to 4.2.2 on Monday and this is affecting us also. The launch/connect button to start the app opens a new tab for server apps e.g. Jupyter, RStudio VS Code etc. however all of our GUI apps e.g. Desktop, Paraview are opened in the current tab.
I canāt seem to open the app in a new tab even if I right click on the launch button:
I tried setting new_window: true in the appās manifest.yml file but that didnāt fix it, as you said it must just be for app in the navigation bar.
I was going to edit the appās view.html.erb as you suggested, but none of my GUI apps even have that file by default. Is it generated automatically for those apps? Do you know what it should contain?
I tried:
<form action="/node/<%= host %>/<%= port %>" method="post" target="_blank">
<button class="btn btn-primary" type="submit">
<i class="fa fa-eye"></i> Connect to Desktop
</button>
</form>
using my Jupyter app view.html.erb as a template but that gave me a proxy error. The URLs for the GUI apps are much longer i.e. ood-server/pun/sys/dashboard/noVNC-1.3.0/vnc.html?autoconnect=true&path=rnode%2***%2****%2Fwebsockify&resize=remote&password=****&compression=9&quality=9&commit=Launch+Trillium+Desktop.
I was able to regain the old behaviour by re-adding :formtarget => ā_blankā and target: ā_blankāto /var/www/ood/apps/sys/dashboard/app/views/batch_connect/sessions/connections/_novnc.html.erb:
<%= f.submit( t('dashboard.batch_connect_sessions_novnc_launch', app_title: app_title), class: 'btn btn-primary', :formtarget => "_blank") %>
<% if connect.spassword.present? %>
<%= link_to t('dashboard.batch_connect_sessions_novnc_view_only'), novnc_link(connect, view_only: true), class: 'btn btn-light float-end border border-dark', target: '_blank' %>
<% end %>
Yes that is a viable solution to change the partial. Though you shouldnāt edit the files we ship. Instead you can override the partial in /etc so that when you upgrade/update you donāt have to go back and edit the file forever.
Even if a link opens in the same tab by default, an individual user can right click and decide to open in a new tab if they wish
I do not understand this statement. Where and when an individual user can click and decide to open a new tab? Right now they see a Launch button that makes their OOD dashboard to disappear, and have to navigate back and forth. I would very much like to revert to the original behaviour of opening new tabs.
Update: only the ShareableLink is a link. The Launch thing is a JS thing, it wont right-click.
Update2: arguably, the W3C standard does not prohibit opening new tabs in case of multi-step processes when a previous page is of value ? G200: Opening new windows and tabs from a link only when necessary | Techniques for WCAG 2.0 . I would think, the Interactive Job card makes for such a case. Also, the requirements seems to be to indicate that a new tab would open, which can be just a help message next to the āLaunchā button, or on the very button?
Just wanted to emphasize to everyone that if you work for any type of US base governmental entity (i.e. a public college / university), you will have to comply with federal digital accessibility requirements within the next 2 years or risk being held liable for ADA violations.
There is some ambiguity/nuance in some of the ways to comply, and the standards are slightly evolving. However, the core Open OnDemand dev team has gone through some training on digital accessibility and are doing their best to comply not just with the letter of the law, but also the spirit of the law. As part of our development process we utilize multiple platforms and tools to test digital accessibility (e.g. different screen readers such as NVDA and built-in MacOS and Windows tools).
One of the overall missions of Open OnDemand is to lower barriers to access to research computing, and a technique to facilitate that is to ensure broad digital accessibility. The team did discuss at length whether opening in new tabs or the same tabs was required by the WCAG standards as well as what produced the most accessible results within our admittedly limited dev time and expertise. In some rare situations we felt it was ok to open in a new tab when something was clicked on. But in most situations we felt the best course of action was to stay in the same tab.
That said, we did assume in general that any link would be able to be right clicked on to select the open in a new tab option for those that prefer that. Weāve subsequently discovered thatās not the case, and are trying to figure out if there are ways to add back in that functionality in an upcoming patch.
We acknowledge that this change is disruptive to some members of our community and encourage and appreciate further discussion about it like is happening in this thread.