Chrome crashes on loading file via file picker
JolifantoBambla opened this issue · 17 comments
Describe the bug
I'm trying to load a data set in Aviator using the file picker on Chrome, but as soon as I select the file the browser just shuts down.
When I do the same thing in Firefox (99.0 (64-bit)) or serve the file using http-server it works fine.
Environment:
To Reproduce
- Go to https://avivator.gehlenborglab.org/
- Click on
CHOOSE A FILE - Navigate to file in file explorer
- Click on the OME-TIFF file.
My data set:
Format: indexed OME-TIFF (generated by bioformats2raw+raw2ometiff+generate-tiff-offsets with default arguments)
Datatype: uint16
Resolution: 1024x1024x40
Channels: 29
File size 2.7 GB (OME-TIFF), 13.9 kB (offsets)
I still have to check if I'm allowed to share the data set, but my guess is I'm not :/
Expected behavior
The data set should be loaded and visualized by Aviator.
Environment:
- Release or git hash: 0.12.6 (I'm using the Aviator version served via
gh-pages) - Browser: Google Chrome
- Browser version: 100.0.4896.127 (Official Build) (64-bit)
- OS: Ubuntu 20.04
I think this is the same issue I've run into a couple of times, this happens when I load e.g. LuCa-7color_3x3component_data.ome.tif file locally without the devtools open. It makes me suspect that perhaps this geotiff issue is related, since when I have my devtools open the "Disable cache" flag could have such influence.
I will look into this, but I suspect that since things worked previously and now don't, this is probably an issue with the latest Chrome builds. Things have randomly broken in the past with no announcement. We will look into this.
I can't reproduce this on that example @bbss. I will push something to the avivator deployment to log errors so hopefully you can report at least that.
I've added error logging to the Avivator demo. Please try out your errors now and look at the browser console log. If you don't see anything maybe try in a few hours. I invalidated our CDN cache but I am not sure how long it takes to see the change.
I have been working with avivator for the past month on Chrome and it was working up until today. Now, it just shows a loading wheel and never loads the image. Nothing has changed with the image files that were previously able to load. Perhaps these issues are related somehow? An example of one of our images loaded into the tool: https://avivator.gehlenborglab.org/?image_url=https://bioed.bu.edu/static/ome_tiff_files/MK886_MK-1-5_groupA_18-MK-1-5-emb1001_.ome.tiff
Polling @JolifantoBambla (and @bbss on the second question) two questions
- Is your data Float64?
- Have you tried this out in other browsers?
For @mproberts99 I can see what is happening (at least for this image once I download it locally). @manzt it appears the attrs.cast function has....stopped working for Float64? https://github.com/hms-dbmi/viv/blob/master/src/constants.ts#L81 Really very completely confused here. Must be missing something.
@mproberts99 Are you sure that this image has always worked? Or was this just a way of showing that any file off this server does not work? It appears that your server is mis-configured (judging by the error messages from Firefox/Safari). It's strange that Chrome just hangs.
Separate from the (apparent) issue with server, there was a bug with Float64 data that I have hopefully remedied: #594
@ilan-gold we did have server issues a few weeks ago, but we solved it by generating offset.json files for every image and this link was working up until very recently. I see the errors you're talking about on Firefox/Safari regarding the file type being incorrect. When we were originally having server issues that same error popped up on Chrome so this loading wheel output is new and what makes us think it's a different problem. We also haven't changed the images on our server since we got it to work
@mproberts99 I will look again later, but I really think that your server is the issue unfortunately at least in other browsers. We have seen this error before: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://bioed.bu.edu/static/ome_tiff_files/MK886_MK-1-5_groupA_18-MK-1-5-emb1001_.ome.tiff. (Reason: header ‘range’ is not allowed according to header ‘Access-Control-Allow-Headers’ from CORS preflight response). It usually means the server is sending back a reply that does not include Range in access-control-allow-headers. For example, the HuBMAP project also hosts its own data as in https://avivator.gehlenborglab.org/?image_url=https://assets.hubmapconsortium.org/15039c1e4e77bd81b297ff9fd98711ca/ometiff-pyramids/processedMicroscopy/VAN0031-LK-3-63-PAS_IMS_images/VAN0031-LK-3-63-PAS_IMS-registered.ome.tif?token= but in the response headers there is access-control-allow-headers: DNT,User-Agent,Authorization, MAuthorization,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range. Could you try configuring your server to respond with this?
Unrelated to that (please try that in different browsers), it would appear Chrome has stopped working for all images? I can't even load https://avivator.gehlenborglab.org/?image_url=https://viv-demo.storage.googleapis.com/idr0106.pyramid.ome.tif
Sorry for closing this issue prematurely, but I believe that we actually have now fixed the issue. We missed an instance of loadOmeTiff - both of us have confirmed that we can use the Chrome file picker again.
Hey @ilan-gold, sorry for the delay, I've been sick last week.
Is your data Float64?
No, uint16
Have you tried this out in other browsers?
Yes, Firefox 99.0 (64-bit Linux) works fine.
I've just tried it with the following two Chrome versions:
- 100.0.4896.127 (Official Build) (64-bit)
- 101.0.4951.54 (Official Build) (64-bit)
In both versions the browser simply crashes (all Chrome windows close without writing anything to the log file) as soon as I click on the file in the file explorer.
The last line in the log file is:
[207698:207729:0509/153910.934038:VERBOSE1:bus.cc(708)] Requested to remove an unknown filter function: 1 with associated data: 0x2fc600b582a0
But that line was written before I clicked on the file and the browser crashed.
Thanks for getting back so quickly, I'm using viv from a ClojureScript project and need to run babel before running it through the Google Closure compiler. I've not yet been able to get this working with the the recent updates to geotiff (0.12.6 vs 0.12.5).
I don't want to confuse issues related to this compilation but I've run into some issues with Chrome devtools completely stalling and crashing without finding an error, this is with the LuCa-7color file, but I think this only happened with advanced Google Closure compilation, which does some optimizations that could cause runtime behavior changes. Right now I can't reproduce but I do have an issue with local files still.
When loading the file from local with Disable cache enabled then it loads fine, if I disable it/don't have devtools open I get AggregateErrors from BlockedSource.
This happens with chrome Version 101.0.4951.54 (Official Build) (arm64) and does not happen with firefox.
I weighed in because I thought I hit similar errors with the LuCa-7colors files, that happened in chrome and not firefox.
Note that this is not a blocker for me right now and I will get back to the issue crash issue later when I succeed in compiling the latest viv/geotiff changes. Thank you!
Ok @bbss i think then until we or the geotiff folks have a reproducible example this will be a bit challenging to address. @JolifantoBambla I am curious if your issue happens on other computers with the file, or on your computer with the same file. This'd be a good way to tease out what might be happening. And if it looks like the issue is the file and you can share the data, that'd be great!