-
-
Notifications
You must be signed in to change notification settings - Fork 94
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTML from build sometimes doesn't include content #40
Comments
Hello! Glad you're enjoying the project 馃槃 I've never seen this behavior, could you try to narrow down how to reproduce it, and give some more context like screenshots, or the files with the missing content, etc. That would be a big help. Thank you! |
Sure thing. So for example, the elm-pages blog has the "wrong content" issue as well. Here's the static html for your https://elm-pages.com/blog/introducing-elm-pages blog post. If you'll look at the title, you'll see it's the wrong one. It's the one of the home page, not the blog post. If you disable javascript, you can see it renders the home page: Will look into this a bit more. PS. When you refresh the elm-pages blog, it says "Missing content" for a second. |
Some notes:
|
Hey! Thanks for taking the time to give more context. I have definitely seen the flash of the "Missing content" message, but I don't think I've been able to reproduce the wrong content issue (maybe I'm missing something in the steps for how to reproduce it).
Yeah, so what that's doing is it runs both as a headless CLI app ( |
In the headless CLI version, the content is placed in the generated In the browser version (not the CLI version) of the generated |
No worries! The small start-up I work at would love to use elm-pages. This issue is sadly a deal breaker, so I'm doing what I can to help it get fixed
Sorry for not communicating this clearly. But the screenshots I posted above were from your elm-pages website (ie. https://elm-pages.com/blog/introducing-elm-pages). The issue being here that your blog post 鈽濓笍 has the static HTML of the index page. Or, in other words, the rendered HTML file you've put on the server does not contain the actual blog post. Another way you can see this, is when you disable javascript and refresh the page (see screenshot). |
Hey! Thanks, I appreciate the help in trying to reproduce the issue! I tried reproducing it with JavaScript and I see what you're talking about. It's pretty strange, I didn't see that when I disabled JavaScript in Brave (it showed the correct page). Also, if you do a curl command: curl https://elm-pages.com/blog/introducing-elm-pages/ You can see it has the correct title: <title>Introducing elm-pages 馃殌 - a type-centric static site generator</title> So I'm not sure what's going on here, it seems like it might be something strange with Firefox? I'm not sure what would cause fetching a simple HTML file with no JavaScript running to have different behavior in different browsers. Any ideas? |
This is interesting, it looks like Firefox isn't fetching that document from the server with JavaScript turned off. It's getting it from the service worker. Strange that the service worker is used at all with JS turned off 馃し鈥嶁檪 But that might explain why the homepage comes back in that case (and why the behavior is different in other browsers with JS turned off). What happens is that when the app is offline is that the service worker will always give you the shell application. Because the shell is the same for all pages, and when it's offline then you don't want to store the HTML for each individual page because it has redundant information. So it seems like turning JS off here is creating a sort of artificial condition that wouldn't happen otherwise. The fact that it serves from the service worker when JS is turned off seems like a strange choice, and like it wouldn't match up with the real behavior for a user that has JS turned off. But if you have something else in mind, could you describe the use case that you're trying to support here? Thanks for the discussion, it's a good topic! 馃槃 |
Scratch that, it doesn't make a difference. But the correct content shows up in Firefox if you do a hard refresh (i.e. Firefox bypasses the service worker when you do a hard refresh). |
If it helps I'm also seeing this at https://sunrisemvmtsb.org in Chrome. I spotted it loading the correct HTML from the server, and then once the client takes over it renders the missing content warning followed by the page content again. |
If you go to about:serviceworkers in Firefox and click "Unregister" for the elm-pages.com service worker, then it works as expected. So to summarize, the problem you're encountering is only specifically when both:
I think this is just an eccentricity of the Firefox dev tools. I can't think of a reason a user would have JS disabled but keep service workers enabled. What do you think? |
Oh interesting, I didn't think the service worker would kick in at this point. Damn, caching can get complicated 馃槄 So, some thoughts here:
|
Oh man, yeah caching and service worker logic gets really tricky! I've spent so much time digging into it and thinking about how to handle these different cases! Using fallback of the shell HTML is one of things that I've arrived at as a best practices. Here's a brief description of how to do that with workbox (which is what elm-pages uses under the hood): https://developers.google.com/web/tools/workbox/modules/workbox-routing#how_to_register_a_navigation_route It's worth noting, I am just rendering the home page here, which is just a simple way of doing that. It should really be a blank page, it's just a lot of work to get it to do that and for not too much benefit. It's on the roadmap, but not at the top of the list, to have the fallback page have an empty body. Regarding Firefox using the service worker when you have JS turned off... it's pretty odd because, 1) the service worker itself is just a JS process, and 2) the service worker is registered by running this JS code: <script>
if ("serviceWorker" in navigator) {
window.addEventListener("load", () => {
navigator.serviceWorker.register("/service-worker.js");
});
} else {
console.log("No service worker registered.");
}
</script> So the only time you would run into that situation is if you first load the page with JS, and then turn off JS through Firefox's dev mode options (I'm guessing turning off JS through other means in Firefox disables service workers? but maybe not?). Also, yes it is really strange that gets the fallback URL in those cases... seems like the service worker code itself is behaving strangely and is hitting the code for when the site is not reachable. Seems like a Firefox bug to me, because you're not offline so it shouldn't get the fallback, it should go directly to the network. For the other points:
Could you describe those other points more? The service worker stuff is definitely tricky, and if there's something I'm missing I'd love to hear more details. There is one known issue with the service workers, which is that you can't access files from the
Yeah, if you look at the network tab, it tells you where the data is being served from, and you can see that it says it's coming from the service worker cache in these cases.
Yeah, as I went into in the beginning of the message, I believe this is a Firefox bug. Correct me if I'm missing anything, but this workbox code is what I'm using to tell it to use the fallback routing in the case that it's offline. So I guess the bug is either with that workbox code, or with the Firefox No JS setting.
That's a lot of stuff! Feel free to also DM me on Slack or message in the #elm-pages channel there. If there's more to discuss, I'd be happy to do a video call some time, too! Thanks for all the feedback! |
Thanks for the detailed description, appreciate it!
Makes sense yeah 馃憤
I did have the problem in Chrome as well. I guess we can confirm this behaviour by looking at the response in the dev tools? Testing:
So, I'm online, I shouldn't get the version from the service worker, right? And the
My pleasure |
Looking at the service worker code, I'm guessing this code:
Which is called from https://github.com/GoogleChrome/workbox/blob/194cdeb63d5abb21490f88f01f02f4bcf7e6d54b/packages/workbox-precaching/precacheAndRoute.mjs#L30 Or am I misinterpreting something here? 馃 |
Interesting,
(From this section of the docs: https://developers.google.com/web/tools/workbox/guides/codelabs/webpack#inject). See also this page which talks about how to precache assets with Workbox: https://developers.google.com/web/tools/workbox/guides/precache-files. It uses some magic to turn Since it's only adding elm-pages/generator/src/develop.js Line 210 in 815dec7
|
Oh interesting. Yeah, you're right, this should indeed work using |
Hey @icidasset, no worries, it's a lot to keep track of! I'm definitely not fully understanding things myself, so I appreciate talking through things with you. |
I've been going through the original issue and some elm-pages code. I would guess the issue is that the "prerenderer" sometimes renders the page when the It might be that Line 34 in 35fbee6
content.json has done loading.
What do you think? Could that possibly be the issue? |
Yeah, there's just a ton of functionality in a static site generator framework, it's tricky to keep track of everything that's going on! Especially if you didn't write the code! The content is already rendered in these cases, you can see that it only calls that https://github.com/dillonkearns/elm-pages/blob/master/src/Pages/Internal/Platform.elm#L406-L411 Also, if you do a simple My impression is still that it's a bug (or strange design decision) with Firefox's behavior when you have 1) a service worker that was previously registered (with JS turned on), and then 2) you turn JS off (using Firefox dev tools). In this case, it appears that Firefox is treating it as if you are offline and not fetching those pre-rendered HTML files from the server, which seems... broken to me. I'd love clarity on what's going on (even if it means my theory being proven wrong 馃槃)! |
Oooh... so I think I know what's going on here. Thanks for giving the screenshot and context, that's helpful! The way the Elm lifecycle works, it calls So I think what's happening is: Cycle 1 Cycle 2 The way to fix this would be by using a MutationObserver, which is something the web platform provides to listen for changes to the DOM. That gets complicated and a little hacky, but it would work. But, I think that the changes I'm working on for #42 will actual also solve this problem So let me try getting a fix out for #42 first, and then let's see if the issue goes away. I believe it will solve it reliably because I'm going to make sure that the Elm app has the |
Thanks so much for fixing #42 @dillonkearns! 馃檹 So no more "Missing content" as before, but just an empty body element. |
Hey @icidasset, thanks for the fast feedback! Sounds like we'll have to explicitly listen for the DOM to change from Elm's view function being called. I'll try to get a branch that you can test out soon (seems like you're able to reproduce it reliably, I haven't been able to reproduce it on my machine). Thanks for helping to narrow this down! |
@icidasset since I'm not able to reproduce this issue on my machine, could you try an experiment for me and let me know how it goes? I just want to prove the theory that the snapshot is being taken before the view function has taken over. Could you add some code right below this line: elm-pages/generator/src/develop.js Line 308 in cae3344
// you'll need an import like this at the top, too
const Renderer = PrerenderSPAPlugin.PuppeteerRenderer
// and then add this in the options for the PrerenderSpaPlugin
new PrerenderSPAPlugin({
staticDir: path.join(process.cwd(), "dist"),
routes: routes,
renderer: new Renderer({
renderAfterTime: 5000 // Wait 5 seconds.
})
}) You can just take the cloned repo, make that change, and then run After we confirm that, I'll try working on a fix, just want to confirm the theory first. Thank you! |
@dillonkearns That seems to fix it 馃憤 |
@icidasset awesome! Thank you for checking! Could you try out this branch and see if the fix works? #61 |
Fixed by #62. |
Hey 馃憢 Thanks for this great project!
I noticed that sometimes when I make a build, the resulting static HTML says
Missing content
(ie. the content isn't there). Also, sometimes the static鈥揾tml content is wrong, instead of missing. For example, sometimes I'm getting content for the index page instead of the blog article.It appears to happen randomly, also tested it with removing the
.cache
directory.The text was updated successfully, but these errors were encountered: