How to Hide Error Messages

[MWhiteFearless]

Hello, thanks for such a great library!

I'm curious what the best way to hide or close an error message is? My use case involves one image per viewer. Sometimes the initial IIIF image api url we pass in fails, in which case we want to use a simple image instead. Currently I have this working with a handler on add-item-failed that uses destroy() and then creates a new viewer with the simple image.

const handleFailedImage = (e) => {
    e.eventSource.destroy();
    OpenSeadragon({ ...config, tileSources: imgSource });
  };

When I try to use open() or addSimpleImage() instead I get this issue where the error message displays behind the new simple image:

I've been able to hide the message here with

let el = document.querySelector(".openseadragon-message");
el.style = "display:none;";

I'm wondering if there's a better way? Sometimes we have 10s of viewers loading on a page, and destroying and recreating them seems potentially more costly than necessary.

A slight side note, but I think it would be great to implement some kind of loading message or spinner while the viewer is fetching the IIIF data, it can take a few seconds for this call to fail and I think this would be a great feature :)

Thank you!

[pearcetm]

It doesn't look like there's a public API for this (yet), but you could use the private API viewer._hideMessage(). Would you be interested in putting together a PR that would create a public API for this?

In terms of a "loading" spinner, you could always position an SVG or GIF or something over the viewer on creation, and remove/hide it once the image loads or fails by listening to those events. Of course, if you come up with a nice implementation you could always open a PR for that as well. There may be more complexity than it first seems, though, if you want to support multi-image mode or other more advanced features.

[iangilman]

@MWhiteFearless After the failure, how do you add the second image? Looking at the code, it seems like it should be automatically hiding the message whenever you call open or addTiledImage, but it looks like it's not doing so for you? That would be good to fix.

[MWhiteFearless]

@MWhiteFearless After the failure, how do you add the second image? Looking at the code, it seems like it should be automatically hiding the message whenever you call open or addTiledImage, but it looks like it's not doing so for you? That would be good to fix.

@iangilman I was wondering if it was intended. The code I'm using for the screenshot in my post is

osdViewer.addOnceHandler("add-item-failed", (e) => e.eventSource.open({ type: "image", url: imageUrl }));

I think the issue might be that the error message does not display until after the add-item-failed event is complete, so it cannot be hidden by the open() call. I get the same result with addSimpleImage()

[iangilman]

@MWhiteFearless That looks like exactly it! Looks like it's happening here:

openseadragon/src/viewer.js

Line 250 in 9b7fc46

this.addHandler( 'open-failed', function ( event ) {

Probably it could just be fixed by bumping up the priority for that handler (by adding null, 10 or something to the end of the addHandler call). You're welcome to make a PR to that effect 😄

Meanwhile if you want to work around it, rounding your open in a setTimeout call you can change the timing. Just one millisecond should be fine.

[pearcetm]

Probably it could just be fixed by bumping up the priority for that handler (by adding null, 10 or something to the end of the addHandler call).

I haven't dived fully into the code here, but it seems like the order in which the add-item-failed and open-failed events are raised might be the culprit, rather than the priority of the handlers (I could be wrong though). Specifically, the order in which Viewer::open-failed versus Viewer::add-item-vailed versus TileSource::open-failed get triggered might be important. Since the error message is added during a listener to Viewer::open-failed, this might be the better event to listen to and handle opening a new image.

[MWhiteFearless]

Yeah you're right! I just tried it with open-failed instead and it works that way. That feels much better than destroying and creating a new viewer, thank you! I'm not sure if there's a code change that would make sense here, but maybe it would be helpful to add that to the documentation at least so the user understands the chain of events that happens better

[iangilman]

Oh, good point! I hadn't noticed the fact that they were different events. Thank you @pearcetm for pointing that out!

And yes, just a little note on both events' documentation would be good. I'll tag this as a documentation issue now.