Zoom issues in Safari (image disappears above certain zoom levels)

[blalbrit]

Expected behavior

When zooming in on an image, expect smooth transition at all resolution levels.

Actual behavior

Intermittent, and only in Safari, image zooms to a certain level and then disappears. Tested in Exhibits, PURL, and over on projectmirador.org with consistent replicability. Suspect this might mean a Mirador/Safari intermittent issue rather than sul-embed-specific, but wasn't quite sure where else to report it. (heck - it might even be down at the OpenSeadragon level). See screen caps below. First report of this behavior was 6/13/22, second report of this behavior was today, 6/23/22.

Steps to reproduce the behavior

• in Safari
• go to https://parker.stanford.edu/parker/catalog/dh967mz5785 (one of two examples reported by users, the other is https://parker.stanford.edu/parker/catalog/qd527zm3425)
• navigate to fol. 1v (though others display the behavior as well - fol. 2r zooms further but then disappears, for instance)
• zoom in - image clips and/or disappears a few levels in
• note: same behavior does not occur in Firefox or Chrome (have been directing users to switch browsers to work around the issue)

  ---

  Secondary test - which makes it seem likely it is not just a sul-embed problem and more likely to be in the Mirador/Seadragon level:

• In Safari, go to projectmirador.org and open up the test instance there
• paste in https://dms-data.stanford.edu/data/manifests/Parker/dh967mz5785/manifest.json to test the object there
• navigate and test as above

  ---

Tertiary test - wanted to double-check it wasn't the custom manifests causing trouble for Parker only

• in Safari, go to https://purl.stanford.edu/dh967mz5785
• navigate to Image 4 and zoom
• behavior consistent with tests aboe

  ---

Final test to make sure it's not a stacks or data problem but seems isolated to interactions within the viewer

• in Safari, go to https://stacks.stanford.edu/image/iiif/dh967mz5785%252F061_001_V_TC_46/full/full/0/default.jpg
• full image loads fine
• testing at different percentages (ie. https://stacks.stanford.edu/image/iiif/dh967mz5785%252F061_001_V_TC_46/full/pct:30/0/default.jpg) also fine, so raw delivery of image in browser seems unaffected, just the zoom action in the viewer environment

Browser / Environment

• both user reports have been in Safari
• Version/15.5 Safari/605.1.15 (first report)
• Version/15.5 Safari/605.1.15 (second report)
• Testing done in Version 15.5

Example 1: Safari-specific behavior

Example 2: Same action in Firefox (showing non-replicable in non-Safari browser)

Impact

• I can work with users to switch browsers as needed for Parker but wanted to flag this for the team just in case it is reported / replicable / or desirable to add to the backlog
• Who knows if this is only relevant to the specific Safari release and will be corrected on the browser side without requiring action on our part? I leave that up to the experts here :-)
• FYI: @caaster

[anarchivist]

Relatedly: this doesn't happen for all IIIF objects, or even all Parker objects in Mirador/SUL Embed on Safari, e.g. https://purl.stanford.edu/bk482mj4247 (a non Parker object.). @blalbrit noted in Slack:

Benjamin Albritton: maybe edge-case jp2 formulas (these were generated back in 2007-2009 - others from that vintage might have same issues but aren’t used as heavily as Parker so aren’t reported/discovered?) Benjamin Albritton: weirdly - not all Parker objects either. Benjamin Albritton: (not even all images within a single object)

[anarchivist]

Per standup today, we're wondering if it's related to a resource limit (see this OSD issue comment, which is about Safari on iOS, not macOS). See also #900 and #1097 - we ran into a similar situation with piano rolls at some point.

[dnoneill]

I was not able to replicated. I however did notice that sometimes when I hit the zoom button it did not work if I just had hit it a second previously so that might have been the solution to this issue.