Skip to content
This repository has been archived by the owner on Jan 11, 2023. It is now read-only.

Sapper legacy mode: CSS not loaded on route change #1505

Closed
rodoch opened this issue Sep 12, 2020 · 17 comments · Fixed by #1525
Closed

Sapper legacy mode: CSS not loaded on route change #1505

rodoch opened this issue Sep 12, 2020 · 17 comments · Fixed by #1525

Comments

@rodoch
Copy link
Contributor

rodoch commented Sep 12, 2020

Describe the bug
This issue occurs when using a production build (npm run build) of Sapper created with the --legacy flag in a browser which relies on the legacy code (i.e. a browser with no native support for async/await syntax).

When navigating from Page A to page B the CSS associated with the page B route is not loaded and the contents of page B remain unstyled. This does not affect the styling of any components already loaded on page A.

Logs
When testing this in Chrome 54 the console displays the following errors:

service-worker.js:1 Uncaught SyntaxError: missing ) after argument list 
(index):1 Uncaught (in promise) TypeError: Failed to register ServiceWorker: ServiceWorker script evaluation failed

However, this appears to be unrelated to the problem. Removing the service worker from the project and rebuilding does not alleviate the issue.

To Reproduce
I've created a minimal repro here: https://github.com/rodoch/sapper-legacy-repro

This is simply a copy of the sapper-template repo with Sapper & Svelte versions bumped to 0.28.6 and 3.25.0 respectively. To reproduce the problem you need to use a 'legacy' browser. I have reproduced with Chrome <= 54 and Safari <= 9 (via BrowserStack and on an old Windows machine).

  1. Start by opening the URL localhost:3000/blog. This page is styled correctly:

pic

  1. Next, navigate to the homepage. The content of this page is unstyled (e.g. the size of the success kid picture is unconstrained).

pic

This behaviour is not evident if you start on the homepage and move to the blog, presumably because a sufficient set of styles have been applied on initial page load when moving in this direction. With more complex apps this behaviour can be observed on all navigations subsequent to the initial page load.

Expected behavior
The relevant styles should be applied with each route change.

Information about your Sapper Installation:

  • The output of npx envinfo --system --npmPackages svelte,sapper,rollup,webpack --binaries --browsers
 System:
    OS: Windows 10 10.0.18363
    CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
    Memory: 5.08 GB / 15.88 GB
  Binaries:
    Node: 12.13.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.13.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 85.0.4183.102
    Edge: Spartan (44.18362.449.0)
    Internet Explorer: 11.0.18362.1
  npmPackages:
    rollup: ^2.3.4 => 2.26.11
    sapper: ^0.28.6 => 0.28.6
    svelte: ^3.25.0 => 3.25.0
  • Your browser

Discussed above.

  • Your hosting environment (i.e. Local, GCP/AWS/Azure, Vercel/Begin, etc...)

Local + Azure deployment.

  • If it is an exported (npm run export) or dynamic application

Dynamic.

Severity
This is blocking any migration to v0.28 for me.

Additional context
I noticed a similar issue to this with modern browsers after initially migrating to v0.28.x. These issues appeared to be fixed in 0.28.6. I wonder if perhaps those changes didn't extend to the legacy mode.

I should also point out that all of necessary files (both JS and CSS) appear to be generated in __sapper__/build dir. They are simply not requested/applied on navigation.

I'm not sure if this part is relevant but it appears to be on a legacy browser that all assets which are loaded are requested from client/assets and not client/legacy/assets.

@benmccann
Copy link
Member

Thanks for providing a way to reproduce @rodoch. I don't have a legacy browser available to use for testing at the moment, but I expect that #1508 would fix this. Could you give it a try and let me know?

@antony
Copy link
Member

antony commented Sep 14, 2020

@benmccann you're on the browserstack account :)

@benmccann
Copy link
Member

Sapper 0.28.7 is out now. Can you test with the new version?

@rodoch
Copy link
Contributor Author

rodoch commented Sep 16, 2020

Thanks @benmccann. Bad news, I'm afraid this version is crashing completely on legacy browsers. I'm getting error 500 __inject_styles is not a function.

pic

Can repro with the normal sapper-template, just bump the Sapper version number. Tested with Chrome 54, Firefox 53 on Browserstack, Mac & Windows machines.

@benmccann
Copy link
Member

benmccann commented Sep 17, 2020

I just tried using our BrowserStack account and didn't have any issues loading the rollup template with IE 11.

The file __sapper__/build/client/legacy/client.0a8cbac2.js has import __inject_styles from './inject_styles.js';. The file __sapper__/build/client/legacy/inject_styles.js exists for me.

Though I think import is not supported in IE 11, so I'm not sure why it's working for me?

@rodoch
Copy link
Contributor Author

rodoch commented Sep 17, 2020

I think IE11 is working for you because the client bundle isn't being executed at all (because, as you say, import is not supported) so what you're looking at is the server-rendered site. If I kill JavaScript in Chrome 54 it works for the same reason. As far as I can see the client JS bundle is broken in legacy browsers.

@benmccann
Copy link
Member

benmccann commented Sep 17, 2020

It works for me in IE11 on both first page load and navigating between pages, but I do see an issue in Chrome 54:

Uncaught SyntaxError: Unexpected token import

I see that shimport is being used, but it looks like it's erroring:

Cannot read property 'default' of undefined

@rodoch
Copy link
Contributor Author

rodoch commented Sep 17, 2020

It works for me on IE11 too but I suspect that is because the client JS is not executing at all and you are essentially navigating a server-rendered site. I could be way off though! I really don't know anything about shimport but according to the blurb on that repo it works for all kinds of import types.

@benmccann
Copy link
Member

Yeah, I think you're right. I see an error in the console in IE 11:

Object doesn't support this action
shimport@1.0.1.js

@benmccann
Copy link
Member

The error we're getting in Chrome 54 is unexpected token import on this line:

const href = new URL(file, import.meta.url);

@rodoch
Copy link
Contributor Author

rodoch commented Sep 17, 2020

Is the import in import.meta.url the result of a dynamic import()? (I had a look at the source code but can't make out where import.meta.url is coming from.) Chrome doesn't support imported Javascript modules, dynamic or otherwise, until Chrome 61. Probably a similar timeline for Safari and Firefox. If this is the case that might go to explaining the problem.

@benmccann
Copy link
Member

Sapper has a Rollup plugin that adds it. See my last comment that shows where it's coming from. We use shimport to support import statements in legacy browers, but it doesn't support import.meta.url currently, so perhaps we can add support there

@benmccann
Copy link
Member

benmccann commented Sep 17, 2020

@rodoch I can't reproduce this error with https://github.com/antony/sapper-ie. I wonder if you have your IE babel config, polyfills, etc. setup the same way as that project?

@rodoch
Copy link
Contributor Author

rodoch commented Sep 17, 2020

I was getting this error with just the base sapper-template project where the only change I made was to bump Sapper up to 0.28.7.

Do you reckon this behaviour is being polyfilled somehow in the sapper-ie project? I am familiar with it and I have other sites with a similar setup. I will investigate.

@benmccann
Copy link
Member

I think IE is still broken after all. I think it was simply that the script was entirely broken, so it was doing a server-side navigation and looked like it was working

@rodoch
Copy link
Contributor Author

rodoch commented Sep 18, 2020

I'm following the new PRs a little - thanks for your work on this.

I'm not sure IE was ever supported out of the box. I'd be happy just to see the basic template working on 2016+ versions of Chrome, Firefox, Safari, Edge. IE support could be addressed in @antony's sapper-ie template (I realise that is not an official repo, but I'd be happy to contribute to it. I don't think Sapper ever held out IE support officially.)

@rBok6
Copy link

rBok6 commented Sep 19, 2021

Thanks @benmccann. Bad news, I'm afraid this version is crashing completely on legacy browsers. I'm getting error 500 __inject_styles is not a function.

pic

Can repro with the normal sapper-template, just bump the Sapper version number. Tested with Chrome 54, Firefox 53 on Browserstack, Mac & Windows machines.

This also happens on UC Turbo browser
Screenshot_20210919-134404

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants