Answer appears in console (developer tools) but not in the VSCode window.

[ewebgh33]

Before submitting your bug report

• [X] I believe this is a bug. I'll try to join the Continue Discord for questions
• [X] I'm not able to find an open issue that reports the same bug
• [X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS:Windows
- Continue:v0.8.6
- IDE: VS Code
Ollama  v0.1.22

Don't make me join the discord for errors like this please.
Not everyone wants to sit in discord all day.

Description

Continue doesn't output anything. As per screenshot. Using Codellama:34b-instruct

It says "here is the revised code" then shows a blank box. Repeatable.

To reproduce

1. Highlight code.
2. Control+shift M
3. Code appears over in the Continue panel.
4. Ask it to rewrite for XYZ case.
5. It says yes, then doesn't show anything. 6 Nothing else happens. 7 Asking it again still has no effect.

Is this an issue with this model? Or something else? As below - looks like some kind of formatting issue? Printed answer in console but never made it to the window in VSCode. Big red errors in console (see below)

Log output

Interesting. In the log I can the answer, but the answer doesn't make it to the UI.

Your answer should be given inside of a code block. It should use the same kind of indentation as above.
[/INST] Sure! Here's the rewritten code you requested:

console.ts:137 [Extension Host] 
console.ts:137 [Extension Host] params = {
console.ts:137 [Extension Host]     "chain": "eth",
console.ts:137 [Extension Host]     "format": "decimal",
console.ts:137 [Extension Host]     "media_items": True,
console.ts:137 [Extension Host]     "normalize_metadata": True
console.ts:137 [Extension Host] }
console.ts:137 [Extension Host] address = "0x56681458E00CafE1206313D2D033946f458FDEfD"  # Example address
log.ts:441   ERR Cannot read properties of undefined (reading 'data'): TypeError: Cannot read properties of undefined (reading 'data')
    at c:\Users\COMPUTERFACE\.vscode\extensions\ms-python.vscode-pylance-2023.12.1\dist\extension.bundle.js:1:139734
    at _0x1be708 (c:\Users\COMPUTERFACE\.vscode\extensions\ms-python.vscode-pylance-2023.12.1\dist\extension.bundle.js:1:152918)
    at async ve.provideCompletionItems (c:\Users\COMPUTERFACE\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:143:53055)
index.js:2877 undefined Objectchildren: [{…}][[Prototype]]: Object
webviewElement.ts:513 An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.
mountTo @ webviewElement.ts:513
index.html:1003 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'nonce-eb5964e2-9a3a-4201-ad27-5e3a16f4d508'". Either the 'unsafe-inline' keyword, a hash ('sha256-sOhztCLcQDj6UWemcAVe4e2bOyfl2/NxbQbrHagsVAo='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

(anonymous) @ index.html:1003
index.html:1003 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'nonce-eb5964e2-9a3a-4201-ad27-5e3a16f4d508'". Either the 'unsafe-inline' keyword, a hash ('sha256-ejPF0UgHDz5DDACaM9ML1/Z4iJ/wDB06uArgh4n+Q/0='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

(anonymous) @ index.html:1003
index.html:1003 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'nonce-eb5964e2-9a3a-4201-ad27-5e3a16f4d508'". Either the 'unsafe-inline' keyword, a hash ('sha256-sOhztCLcQDj6UWemcAVe4e2bOyfl2/NxbQbrHagsVAo='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

(anonymous) @ index.html:1003
index.html:1003 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'nonce-eb5964e2-9a3a-4201-ad27-5e3a16f4d508'". Either the 'unsafe-inline' keyword, a hash ('sha256-ejPF0UgHDz5DDACaM9ML1/Z4iJ/wDB06uArgh4n+Q/0='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

(anonymous) @ index.html:1003
index.html:1003 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'nonce-eb5964e2-9a3a-4201-ad27-5e3a16f4d508'". Either the 'unsafe-inline' keyword, a hash ('sha256-sOhztCLcQDj6UWemcAVe4e2bOyfl2/NxbQbrHagsVAo='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

(anonymous) @ index.html:1003
index.html:1003 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'nonce-eb5964e2-9a3a-4201-ad27-5e3a16f4d508'". Either the 'unsafe-inline' keyword, a hash ('sha256-ejPF0UgHDz5DDACaM9ML1/Z4iJ/wDB06uArgh4n+Q/0='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

[sestinj]

@EmmaWebGH Thanks for the report and logs. This appears to be the same as here, which is now number one priority, as it's obviously a fairly large problem.

Aiming to solve this first thing tomorrow morning, but a workaround for before then is to use any version prior to 0.8.5, which is when we introduced the Shiki syntax highlighter

[ewebgh33]

Thanks for that, sorry I didn't see that other bug / realise it was the same!

Will check back tomorrow or later when I can put it properly through it's paces. Been looking forward to it - I can wait a little longer. Thanks!!

[sestinj]

@EmmaWebGH Hi, I have a quick follow-up question: the bug from the other issue happened because our syntax highlighter didn't recognize fortran—were you using a particular language when this happened? If so I want to add it to a list so that the bug doesn't happen anymore, and if not then these might be separate errors after all

[ewebgh33]

@sestinj no it was just regular python. The whole file is just a simple fetch of data via API using the requests library, and the part I highlighted and tried to ask a question about (to the local model via Ollama) was just the setting the params for the request.

[martinguenther]

I experienced the same, using GPT-4 Turbo in a JavaScript project. The output log showed the result, but not the UI.

Also I noticed that sometimes the marked code is shown in the UI and sometimes not, as in the screenshot where only the line numbers are shown.

Restarting VS Code temporarily fixed the issue - but it quickly came back. I now switched to pre-release v0.9.46 as suggested in #793. This seems to work. I'll comment if I experience any further issues throughout the day.

[freakontrol]

Hi, I still have the same kind of error, I'm using vscodium in linux mint and continue v0.9.49 using a local LLM with oobabooga. In console I saw lot of: "Refused to apply inline style because it violates the following Content Security Policy directive: ..." Also for me restarting vscodium solve temporary the problem. It happens often when asking for c++ snippets.

[martinguenther]

Just a short follow up: I'm now on V0.9.49. Both .46 and .49 have worked for me since and have always shown the results from LLM in the UI of VS Code.

But, I noticed an issue with code highlighting. Often times it does not work on the code blocks of the LLM's result.

After restarting VS Code and/or switching back an forth (other tabs, or in the history) code highlighting is back, just to disappear again. This is kind of vague - I know - but I could not yet figure out what exactly triggers the error and how to fix it. It seams random to me. Not sure if it's related. Let me know, if I should open a separate issue.

[sestinj]

@martinguenther @freakontrol @EmmaWebGH as mentioned here this was a problem with the Shiki syntax highlighter. In version 0.9.52 (pre-release), we've moved to using Monaco and all of these problems appear to have been solved

I'll wait for confirmation before closing this issue

[ewebgh33]

So we should switch to pre-release for now? Apologies I am not familiar with how long the cycle is for pre-release stuff to make it down to the production release. :)

Right now I am using 0.8.3... Usually I avoid pre-release / release-candidate versions in an effort to avoid introducing other issues.

[martinguenther]

@EmmaWebGH Yes, I believe you should switch to pre-release to get the fix. I've had good experience with it so far. But of course it's up to you :).

@sestinj Thanks for the update. Looks good at first sight :). I'll probably not be able to thoroughly test until tomorrow, 'cause I'm on the road today...

[martinguenther]

@sestinj I was able do to a more thorough check before take-off :). There still seems to be some issues.

1) Mark code in VS Code, hit ctrl + m. The code snippet in the prompt is either missing some lines (left side, 18 lines marked, but only 8 shown), or it shows double lines (right side).

2) Code blocks of LLM result are not always highlighted. I have had a result with three separate code blocks in it, divided by text in between, where the first to were highlighted, the last not. And single code block results which were not highlighted. And then again highlighted. It seems pretty random to me.

I am on version v0.9.53 (pre-release) and currently working on TypeScript code. Let me know, if I can further assist.

[sestinj]

@martinguenther @freakontrol @EmmaWebGH this should now actually be solved in both main and pre-release. Turns out using Monaco was a really bad idea. Just death by paper cuts. So back to the reliable method we'd been using a couple weeks ago, but this time found a way to get themed syntax highlighting.

Since last time I wanted to close this it still wasn't fixed I'll of course wait to close...let me know how it goes for you.

[freakontrol]

I can confirm that the issue is not happening anymore. Thank you!

[martinguenther]

I can confirm too. Looks good. Thanks!