-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix tracks hanging in safari and polyfill for bigwig tracks #3256
Conversation
just for some extra detail while debugging, the main thing seen was that e.g. in WebWorkerRpc, if a track was hanging (which can be reproduced pretty reliably in safari), it would console.log in WebWorkerRpc (on the client side) but would never log in rpc.worker.ts (on the server side) It was not just slow or race-condition-y in this sense, it would just never any code in the rpc.worker.ts. But after this change, it reliably runs code and initializes rpc.worker.ts |
57d56b8
to
4ada1b0
Compare
just as a general observation, side scrolling is much choppier in webkitgtk than it is in firefox or chrome on my computer. |
4ada1b0
to
8d945c6
Compare
Codecov Report
@@ Coverage Diff @@
## main #3256 +/- ##
==========================================
- Coverage 59.41% 59.39% -0.03%
==========================================
Files 674 674
Lines 28782 28783 +1
Branches 7008 7014 +6
==========================================
- Hits 17101 17095 -6
- Misses 11406 11413 +7
Partials 275 275
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
12c9d86
to
3001909
Compare
can confirm fix on a real safari on mac. also found another safari issue with usage of BigInt which was used in bbi-js 2.0.0 upgrade, but this fails in safari 14 which is not that ancient (https://en.wikipedia.org/wiki/Safari_version_history#Safari_14) so I added a polyfill to help |
this fix is pretty weird. i think it reliably fixes though, so might merge for now if we want to revisit we can perhaps dig into it and report a small reproducible issue to webkit. also could perhaps look into whether it's related to our librpc/look into removing librpc from our codebase in favor of a smaller library |
I found that safari/webkitgtk, tracks can hang in #3245
This seems to be a safari/webkitgtk only bug
I found an odd workaround where if I console.log the value returned by makeWorkerHandle (which is a "new Worker" https://developer.mozilla.org/en-US/docs/Web/API/Worker/Worker instance) then it removes the issue with tracks hanging. This seems odd, perhaps indicative of a race condition, but I did not see issue after doing this change.
Fixes #3245
Also found two instances where tracks (pileup and snpcoverage) were using view.staticBlocks before view.initialized was completed, which throws a hard error, so that was also fixed. These errors were not seen in other browsers but i did see it thrown in safari