Jump to z-index

[rastogi-bhavya]

Features Added

Jump to a particular z index. UI has been added which allows the user to jump to a particular Z Index. This z index should be an integer greater than equal to 0. If the Z index entered by the user is not found in the database, the closest Z index would be shown along with an alert showing the user that the desired Z index was not found.

Things Pending

• [x] Integer only for z index input box
• [x] Add proper error messages
• [x] Flow check when the user jumps to Z index and while this request is being processed increases the size of the page which lead to sending out a 2nd request to fetch more data to fill the page.
• [ ] Add a min-width to the z plane list so that when the size of the page is reduced below a certain size, a scroll bar appears and the user would have to scroll at this point rather than reducing the size on the z plane list to 0.
• [x] Update hasNext when the size of the page is decreased when on the last page. Eg last page = 150 - 160. Now the page size is decreased so that the page is 150-155. This means that now more data can be fetched and therefore hasNext should be updated.
• [x] Remove logs

[rastogi-bhavya]

Resize issue in firefox

For https://dev.gudmap.org/chaise/viewer/#2/Gene_Expression:Image/id=16-2GJM, when you go to z index 1 -> 2 -> 1, the resize event no more fires when the size of the page is reduced, causing the UI to break. The resize event fire only when the page size is increased beyond the point, after it, stopped working. To reproduce this, go to a z index having annotations, then go to one not having annotations and then to the first one.

I tried using window.addeventlistener('resize',...) and window.resize() they also do not work after the above mentioned scenario.

[RFSH]

@rastogi-bhavya Please stop saying "Update " in your git commits. The actual comment itself should tell what you did not the description of it.

Regarding your questions,

1. What all error messages need to be shown?

Since we decided to mask the inputs and disallow non-integer inputs, the only error that I can think of is the one that we couldn't find the actual zindex. I added the skeleton for it in chaise, update the message based on what you think is good. And then we can review.

2. How should I decide the min-width of the z plane list?

We should try some heuristic and then later see if our users agree or not. But I think making sure that you can fit at least 2 images should be a good starting point.

3. For handling the case when a z index is searched and the page size is also increased at the same time, I have to make it look like first the z index was searched and then the page size was changed, right?

I'm not entirely sure what you mean. As soon as we're sending a request to chaise (either by user initiation or just width change), all the buttons should be disabled and the spinner should show up. So in this case, user clicks on the button, the input and buttons will be disabled. Changing the width of the page shouldn't change what you're showing (everything should be disabled and spinner is visible). But you would have to send another request with the same input and different pageSize.

Disabling all the button would allow us to make sure that users are doing a single action. So the request that we're sending to chaise is always either page change or finding z-index. And because of this, we can have a single function that talks to chaise. You just have to remember what was the previous user action, so you can send the proper request to chaise. To better explain this, let's go over some different scenarios:

Scenario 1:

• During the page load osd viewer will send a find z-index (based on default z-index value) to chaise.
• While the request is being processed, users change the page width. Since the previous request was finding z-index, we have to send another find z-index request with the new pageSize value to chaise.

Scenario 2:

• Let's assume the page is fully loaded. User clicks on next button, so osd viewer will send a page change request to chaise.
• While request is being processed, user changes the page width. So we have to send another page change request with the new pageSize.

Scenario 3:

• Let's assume page is fully loaded. User searches for a specific z-index, so osd viewer will send a find z-index to chaise.
• After the page fully loads, user changes the page-size. So osd viewer will have to send a find z-index request with the updated pageSize to chaise.

So it really doesn't matter if there's a pending request or not. Whenever you need to update the page, you just have to remember user's previous action and send an updated request. The requestID should prevent from showing stale data.

Also, we have to change the logic that you have to optimize the page size shrinkage case (the one that you're not sending any extra request and are just hiding the extra images).To properly fix it,

• You can only use this optimization if there isn't any outstanding request.
• If the previous user action was finding a z-index, you have to make sure after manual shrinkage, the selected z-index is visible.

[RFSH]

Just to summarize what's left:

• Firefox bug when switch from an image without annotation with an image with annotation (this is present in master too, so it's not a blocker for these changes and I'm currently looking at it)
• Adding min-width fallback (not a blocker and can be done later)
• Cleanup the code
• Making sure the recent changes work properly
• Going over regression test cases

[RFSH]

I made some changes to this PR,

• I realized that since we're showing the error in chaise, it could show multiple errors for stale requests (if you search for an out of range z-index and then change the page size while the request is pending, two errors will show up)
• Changed the input so it works without the need for pressing enter. Also the search will only fire if the input has changed to a z-index other than the image that is already displayed.
• Made some modifications to the input to make sure we're supporting cases like "0000". We don't need to check for leading 0, we just needed to call parseInt to handle any values for us.

I also added new cases to regression test for this feature.