sul-dlss
Zoom issues in Safari (image disappears above certain zoom levels)
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
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)
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.
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.
I also am unable to duplicate this. My assumption is that Safari is fixed. @blalbrit can you see if you can duplicate it?
