Theme images on the welcome page are broken #4483

Activity

1. jsjoeio

   added

   bugSomething isn't workingSomething isn't working

   on Nov 10, 2021
2. jsjoeio

   added this to the 3.12.1 - improve release process milestone on Nov 10, 2021
3. jsjoeio

   self-assigned this

   on Nov 10, 2021
4. code-asher commented on Nov 10, 2021

   

   code-asher

   on Nov 10, 2021

   Last edited by code-asher

   Member

   More actions

   To test:

   1. Open the "Get Started" sub-page (can get there from the main welcome page)
   2. Make sure you are on the first step ("choose the look you want")
   3. Observe broken images

   The images do exist and you can open them manually so it is unclear why they fail to load.

   👍React with 👍1Reacted by Joe Previte
5. jsjoeio

   modified the milestones: 3.12.1 - improve release process, 4.0.0 on Nov 10, 2021
6. jsjoeio

   unassigned

   jsjoeio

   on Nov 12, 2021
7. jsjoeio commented on Nov 12, 2021

   

   jsjoeio

   on Nov 12, 2021

   ContributorAuthor

   More actions

   I will probably pick this up Monday or Tuesday (might not have time today).
8. jsjoeio commented on Nov 12, 2021

   

   jsjoeio

   on Nov 12, 2021

   ContributorAuthor

   More actions

   Verified this is still an issue

   

   Errors observed in the console:
   

   index.html:1 Mixed Content: The page at 'https://d9385a7a-36ed-4047-9202-43fc2176f639.vscode-webview.net/insider/dc1a6699060423b8c4d2ced736ad70195378fddf/out/vs/workbench/contrib/webview/browser/pre/index.html?id=d9385a7a-36ed-4047-9202-43fc2176f639&swVersion=2&extensionId=&platform=browser&vscode-resource-base-authority=vscode-resource.vscode-webview.net&parentOrigin=http%3A%2F%2Flocalhost%3A8080' was loaded over HTTPS, but requested an insecure element 'http://localhost:8080/static/out/vs/workbench/contrib/welcome/gettingStarted/common/media/light.png'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
   index.html:1 Mixed Content: The page at 'https://d9385a7a-36ed-4047-9202-43fc2176f639.vscode-webview.net/insider/dc1a6699060423b8c4d2ced736ad70195378fddf/out/vs/workbench/contrib/webview/browser/pre/index.html?id=d9385a7a-36ed-4047-9202-43fc2176f639&swVersion=2&extensionId=&platform=browser&vscode-resource-base-authority=vscode-resource.vscode-webview.net&parentOrigin=http%3A%2F%2Flocalhost%3A8080' was loaded over HTTPS, but requested an insecure element 'http://localhost:8080/static/out/vs/workbench/contrib/welcome/gettingStarted/common/media/dark.png'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
   index.html:1 Mixed Content: The page at 'https://d9385a7a-36ed-4047-9202-43fc2176f639.vscode-webview.net/insider/dc1a6699060423b8c4d2ced736ad70195378fddf/out/vs/workbench/contrib/webview/browser/pre/index.html?id=d9385a7a-36ed-4047-9202-43fc2176f639&swVersion=2&extensionId=&platform=browser&vscode-resource-base-authority=vscode-resource.vscode-webview.net&parentOrigin=http%3A%2F%2Flocalhost%3A8080' was loaded over HTTPS, but requested an insecure element 'http://localhost:8080/static/out/vs/workbench/contrib/welcome/gettingStarted/common/media/monokai.png'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
   light.png:1 Failed to load resource: net::ERR_FAILED
   dark.png:1 Failed to load resource: net::ERR_FAILED
   monokai.png:1 Failed to load resource: net::ERR_FAILED
9. jsjoeio

   self-assigned this

   on Nov 16, 2021
10. jsjoeio commented on Nov 16, 2021

    

    jsjoeio

    on Nov 16, 2021

    Last edited by jsjoeio

    ContributorAuthor

    More actions

    Notes

    Do the files exist?

    When the images fail to load, the first question we ask is, "Do the images exist in the locations we expect them to exist?"

    In upstream, they live here.

    Looking at our fork, we see them here.

    ✅ Files exist (at least in the correct place).

    Do the files exist in the build output?

    When we run yarn watch, we create an /out directory. Let's check if they exist there.

    I found this here: vscode/out/vs/workbench/contrib/welcome/gettingStarted/common/media/light.png 🤔

    But when we look at the source code using the browser tools, it's clearly missing:

    

    This makes me believe that the file exists in the source code but not the build output 🤔

    pair-programming

    @code-asher the iframe which loads these images uses some Microsoft domain which may be related?

    It could also be the HTTP/HTTPS mismatch. It's weird cause it loads in Chrome, but fails in Brave/Safari as well.

    HTTP vs. HTTPS

    We figured it out! The images are served via http locally, but the iframe expects https so due to the mismatch, the browser says, "Not today" and refuses to serve our images. We figured this out by using localtunnel which serves a localhost address over HTTPS. When you do this, the images load.

    

    The solution? Make the iframe src match the current URL.
11. jsjoeio commented on Nov 16, 2021

    

    jsjoeio

    on Nov 16, 2021

    Last edited by jsjoeio

    ContributorAuthor

    More actions

    (this would break for airgapped users so good thing we are fixing it)

    Notes on Solution

    Looking at vscode/src/vs/server/webClientServer.ts around L303, we want to use the webviewEndpoint but when we do, the iframe is blank 🤔

    iframe src lives in vscode/src/vs/workbench/contrib/webview/browser/webviewElement.ts on L431 and it uses:
    this.webviewContentEndpoint<- this._environmentService.webviewExternalEndpoint <- uses this:

    const endpoint = this.options.webviewEndpoint
    			|| this.productService.webviewContentExternalBaseUrlTemplate
    			|| 'https://{{uuid}}.vscode-webview.net/{{quality}}/{{commit}}/out/vs/workbench/contrib/webview/browser/pre/';

    We think it might expect a unique service worker for each path.

    Asher thinks we should create a new endpoint, webview with a uuid and serve the file.

    Asher found a fix for this - using a unique service worker for each web view.
12. jsjoeio

    assigned

    code-asher

    on Nov 16, 2021
13. jsjoeio commented on Nov 22, 2021

    

    jsjoeio

    on Nov 22, 2021

    ContributorAuthor

    More actions

    Fixed via coder/vscode#16
14. jsjoeio

    closed this as completedon Nov 22, 2021