Arvados

New version first commit: https://dev.arvados.org/projects/arvados-workbench-2/repository/revisions/7f80f22374711ce0c55d7a1657b9039fe84a2c1f
Test run: developer-tests-workbench2: #488
Branch: 16951-Can-refresh-listing-when-opening-context-menu-resulting-in-wrong-item-being-operated-on

Added overlay to prevent modifications while refreshing page contents

New version first commit: https://dev.arvados.org/projects/arvados-workbench-2/repository/revisions/7ebf70dc266ce6a01f930d89e599120641f248da
Test run: developer-tests-workbench2: #489
Branch: 16951-Can-refresh-listing-when-opening-context-menu-resulting-in-wrong-item-being-operated-on

Fixed failing unit tests

Commit 7ebf70dc266ce6a01f930d89e599120641f248da seems to be based on a really old branch, could you rebase or merge with main?

New version first commit: https://dev.arvados.org/projects/arvados-workbench-2/repository/revisions/dd63617d23cd24703e9847a8971af8b069e3ce38
Test run: developer-tests-workbench2: #491
Branch: 16951-Can-refresh-listing-when-opening-context-menu-resulting-in-wrong-item-being-operated-on

Rebased with newest main

This makes sense. I like that it dims the user interface to indicate you can't interact with it. As a minor note, I did notice that because the overlay apparently has no mouse click handler, if I right click on the page while it is in the disabled state, I get the browser's context menu, which was a little surprising.

I'm am concerned that if a reload takes a long time or has an unhandled error, the whole user interface would be unresponsive and force the user to reload the page. Perhaps it could just disable the center panel and leave the left hand tree clickable?

Related to this, when clicking on something on the left hand tree to switch the center panel, it often shows the old content (for a different object) for a few moments until new content is loaded. Given a slow load, the user could mistakenly start interacting with the old content. It would be better if it first cleared the panel and/or disabled it (using the feature in this branch) until the new content was loaded.

New version first commit: https://dev.arvados.org/projects/arvados-workbench-2/repository/revisions/d332a55872ab05bc5ce53c3e62f6e8102d573962
Test run: developer-tests-workbench2: #493
Branch: 16951-Can-refresh-listing-when-opening-context-menu-resulting-in-wrong-item-being-operated-on

Context menu should not be available when refreshing

From experimenting a bit while reviewing #18207, it seems that on the particular case of the project listing, the DataExplorer/DataTable's working prop that relies on the app's general progress indicator is somehow detached from the contents loading action, so that's why previous contents were on display (for example, from the parent project) while waiting for new content. In those cases I think a right-click action would show the context menu of a soon-to-be-removed item.
With #18207 merged, I think this case won't be an issue anymore.

Lucas Di Pentima wrote:

From experimenting a bit while reviewing #18207, it seems that on the particular case of the project listing, the DataExplorer/DataTable's working prop that relies on the app's general progress indicator is somehow detached from the contents loading action, so that's why previous contents were on display (for example, from the parent project) while waiting for new content. In those cases I think a right-click action would show the context menu of a soon-to-be-removed item.
With #18207 merged, I think this case won't be an issue anymore.

That seems like a better solution than effectively disabling the entire interface while operations are happening.

From discussion: confirm that the refresh button clears the data table before loading new content so that you can't click on the old content by accident.

Lucas Di Pentima wrote:

I've tested the current version from main and I'm seeing a couple of things that may need improvement if we want to make this the solution:

• The refresh button as it does go back & forward the app's router history, it makes the app do double the work, and now it's super evident.

I am surprised this was not visible before, but that's pretty bad. Seems like it's waiting for the page to load from the back navigation, before even starting the forward navigation to reload the page? There must be a better way to do this.

• For other projects than the "Home", it seems that the behavior of "loading and then clearing the list" is still happening when using the refresh button or just clicking on the current project's breadcrumb (but doesn't happen when changing projects while browsing, so this may be super easy to fix because the loading prop is tied to the fact that the browser's url changes)

Attached is a 49 secs demo video.

I'm not quite following but if browsing is doing the right thing, we just need to do that everywhere?

I played with ce8i5 cluster a bit.

• Regular navigation works fine under "Projects" seems to mostly work fine. On click it clears the table, and loads the contents when ready as expected.

Here are the issues I'm seeing:

• Hitting the refresh button on a project causes it to load twice resulting in a flicker (it clears the contents, the contents show up, then it clears them again, then the content shows up a 2nd time).
• Navigating to a collection, then navigating back to the parent project or using the browser back button still seems to be showing old results as well as flickering:
  • It displays the project view with the old project contents
  • It clears the contents and shows the loading graphic
  • Then it shows the newly loaded contents
• I went into "Shared with me" and clicked on a project. It showed the old contents, then the loading graphic, then the new contents.