Conversation
There was a problem hiding this comment.
Orca Security Scan Summary
| Status | Check | Issues by priority | |
|---|---|---|---|
| Infrastructure as Code | View in Orca | ||
| Vulnerabilities | View in Orca | ||
| Secrets | View in Orca |
| this.term.loadAddon(this._webLinksAddon); | ||
| // handle context loss and load webgl addon | ||
| this._webglAddon.onContextLoss(() => { | ||
| this._webglAddon.dispose(); |
There was a problem hiding this comment.
i think we need to also call this in the destory() func.
i'm not sure i understand what the onContextLoss does, but shouldn't we try to re-instantiate it after disposing?
There was a problem hiding this comment.
Yeah we need it in destroy() for sure. thank you!
onContextLoss is essentially when the browser loses access to the GPU when rendering (if you do some weird driver updates or some kind of switch between GPUs). it's rare. However, the addon itself runs a timeout internally to automatically reinstantiate after a couple seconds and keeps trying.
There was a problem hiding this comment.
The docs say:
An easy, but suboptimal way, to handle this is to..
Is there a more optimal way to handle this scenario?
zmb3
left a comment
There was a problem hiding this comment.
Do we need a fallback to canvas renderer? Do we need any sort of feature detection in case webgl is not available?
We dont need to, it falls back to the dom renderer by default. Also, the "suboptimal" way I believe is them talking about just disposing and falling back to dom rendering. I checked out vscode and they basically do webgl -> canvas -> dom. I can do the same here
the |
| // wont start looking for the context again until the OS has given the browser the context again. | ||
| // When the initial context lost event is fired, the webgl addon consumes the event | ||
| // and waits for a bit to see if it can get the context back. If it fails repeatedly, it | ||
| // will propegate the context loss event itself in which case we fall back to context. |
There was a problem hiding this comment.
| // will propegate the context loss event itself in which case we fall back to context. | |
| // will propagate the context loss event itself in which case we fall back to canvas. |
|
|
||
| this.term.loadAddon(this._fitAddon); | ||
| this.term.loadAddon(this._webLinksAddon); | ||
| // this.term.loadAddon(this._webLinksAddon); |
There was a problem hiding this comment.
Oh my goodness thank you for catching this
| } | ||
|
|
||
| fallbackToCanvas() { | ||
| console.log('WebGL context lost. Falling back to canvas'); |
There was a problem hiding this comment.
Should we use our logger instead of console here?
There was a problem hiding this comment.
Why are we doing this twice?
There was a problem hiding this comment.
| // to canvas is the webgl context is lost after a timeout. | |
| // to canvas if the webgl context is lost after a timeout. |
There was a problem hiding this comment.
seems safer since it's initially undefined
| logger.info('WebGL context lost. Falling back to canvas'); | |
| this._webglAddon.dispose(); | |
| logger.info('WebGL context lost. Falling back to canvas'); | |
| this._webglAddon?.dispose(); |
There was a problem hiding this comment.
absolutely right. ty

This will add the
xterm-webgl-addonto the web ui (not Connect) to help properly display underscores (and perhaps other characters that we haven't discovered).Tested on Ubuntu 24
Without addon (there should be an underscore between "testing" and "thing")

With addon

changelog: The web terminal now properly displays underscores on Linux