Neuron layout's `inverted-tree.css` not loading in Firefox in live-server

[wbadart]

Hey srid- loving emanote so far as I'm porting over my zettelkasten from neuron. Just ran into the snag below.

Describe the bug

I have a neuron-style Zettelkasten in a subdirectory of an emanote site:

$ exa --tree --git-ignore --level 2
.
├── flake.lock
├── flake.nix
├── index.md
├── index.yaml
├── kasten.yaml
├── kasten
│  ├── 0f4cc4fe.md
│  ├── 0fb9e904.md
...

$ cat kasten.yaml
template:
  name: /templates/layouts/note

Often, when viewing one of the notes under kasten/ the CSS for the inverted tree fails to load (see screenshot below).

This only occurs on the live server (should this be an ema issue?), never on the generated site.

To Reproduce Steps to reproduce the behavior:

mkdir wd
cd wd
echo '# Hello!' > index.md
mkdir kasten
cat > kasten.yaml <<EOF
template:
  name: /templates/layouts/note
EOF
echo '# A note' > kasten/foo.md
emanote run --port 8000

In the just-launched live server, navigate to "A note". Hit Ctrl-Shift-r (or equivalent for your browser and platform) to reload the page without using cached resources; you should observe that inverted-tree.css failed to load.

Expected behavior A clear and concise description of what you expected to happen.

Screenshots

Desktop (please complete the following information):

• Browser Firefox
• Version 103.0.2

Additional context

$ emanote --version
0.7.1.0

From a nix profile install earlier today.

About the conjecture in the title of this issue: I noticed this in the default note.tpl:

https://github.com/EmaApps/emanote/blob/f00c2af837b014c0454dc233749a8c9f8ea490d4/default/templates/layouts/note.tpl#L9

It seems that the error comes from the page requesting an _emanote-static/something from under its own directory (e.g. kasten/_emanote-static/inverted-tree.css), rather than the site root. Since <base> seems to be correctly set to /, emanoteStaticLayerUrl is the only other place I could find where an incorrect prefix might be added to the URL for the requested static resource.

Thanks for your consideration!

[srid]

I can't reproduce this on my system (macOS; Brave browser). Is this happening only on Firefox?

kasten/_emanote-static/inverted-tree.css

Yea, this URL is wrong. Emanote should never be generating it (_emanote-static is a top-level route). On my system, I see:

[wbadart]

It does seem to be FF-specific. Here's Chrome after following my own reproduction instructions:

Something I didn't notice before is that FF seems to initially request the correct inverted-tree.css:

Only to immediately follow it up with a request for the wrong one:

[srid]

So this should be reported to Mozilla right?

Not sure what emanote can do here.

[wbadart]

I mean, it could be a browser bug, in which case I'd be happy to report it upstream.

I just haven't convinced myself that it doesn't have to do with ema's live server. Again, it doesn't happen on the generated site, only on the live preview. Here's an example where the correct CSS is requested after an update (adding "hi" to the note), but the incorrect CSS is requested after saving the file without making changes:

https://user-images.githubusercontent.com/8717474/186248590-66cf02e7-d767-4398-b907-2f535a98e999.mov

I'll continue digging into it on my own time, but if you have any suggestions on where in the system to narrow in on, that'd be a huge help.

[srid]

Ema uses morphdom to patch HTML. It could be a bug in morphdom, as morphdom is used only in live-server.

https://github.com/EmaApps/ema/blob/ddf0a92d9de8e06906dc5ada2dfc9a00a3153a7e/www/ema-shim.js#L9-L17

[srid]

It would be great to get this addressed in the upcoming release (https://github.com/EmaApps/emanote/issues/153). Most don't seem to use Firefox, but a substantial number do I believe.

[sophicshift]

Maybe this was fixed by https://github.com/EmaApps/ema/pull/139 (in ema)? The issue seems very similar.

[srid]

@wbadart Could you try to reproduce this with 74bc63d067bf9971f73a228833c43fe8cb3c3bc4 ?

[wbadart]

Trying to set up a quick dev shell with that particular commit, but I'm new to flakes and can't quite get it to click:

{
  description = "A very basic flake";
  inputs = {
    emanote = {
      url = "github:EmaApps/emanote?rev=74bc63d067bf9971f73a228833c43fe8cb3c3bc4";
    };
  };
  outputs = { self, nixpkgs, emanote }: 
  let system = "x86_64-darwin";
      pkgs = nixpkgs.legacyPackages.${system};
  in {
    devShells.${system}.default = pkgs.mkShell {
      ???
    };
  };
}

Can you please advise how to tweak this to get that fixed version into the dev shell? Thanks!

[sophicshift]

@wbadart I don't use nix or emanote, but since the commit is in master, I think you can use the usual nix installation method (the one in the docs)?

[srid]

Replace ??? with buildInputs = [ emanote.packages.${system}.default ];.

But you can also just run nix run github:EmaApps/emanote[^1] on your notebook directory.

[^1]: Or nix run github:EmaApps/emanote/74bc63d067bf9971f73a228833c43fe8cb3c3bc4

[wbadart]

I can still reproduce in FF (running off of master with nix run github:EmaApps/emanote [thanks for the tip!]).

Poking around in the debugger, I confirmed that the correct inverted-tree.css during the initial page load. The initial page load is followed immediately by a websocket message with new HTML to patch in.

Before setHtml:

After setHtml:

Here's the evt.data used as the new DOM:

https://gist.github.com/wbadart/fd5435185a50261dff56780fcf2de290

And it appears to be correct. Moreover, the HTML on the page after morphdom completes also appears to be correct:

(<base> is / and the URL for the inverted tree stylesheet is _emanote-static/inverted-tree.css)

So I'm still at a loss for the root cause of that incorrect URL being requested, but whatever it is, it seems to be in morphdom, since the page is correct before the call to morphdom and incorrect after. Up to you @srid whether we keep this ticket open for tracking until I run down the morphdom bug or close it out since I'm >=85% sure it's not an emanote issue.

[srid]

I can reproduce this on Firefox on macOS.

Your screenshots also match my observation.

So I'm still at a loss for the root cause of that incorrect URL being requested,

Firefox bug with ignoring <base> when dynamically setting HTML?

but whatever it is, it seems to be in morphdom, since the page is correct before the call to morphdom and incorrect after.

Wait, but you said earlier "Moreover, the HTML on the page after morphdom completes also appears to be correct"? That's also my experience - in the browser inspector, the HTML after does use <link rel="stylesheet" href="_emanote-static/inverted-tree.css"> correctly, yet Firefox is trying to load http://127.0.0.1:9010/demo/_emanote-static/inverted-tree.css as if it suddenly stopped respecting the <base> URL which hasn't changed post-morphdom either.

[srid]

This change fixes it (by bypassing <base> lookup), but obviously it is not the correct fix because we do want all links to rely on <base> as Emanote site is not always served at domain root. I'm convinced that the issue is with Firefox not behaving correctly using <base>; but I'd also like to come up with at least a workaround because I don't think we can expect Mozilla to fix this in time.

diff --git a/default/templates/layouts/note.tpl b/default/templates/layouts/note.tpl
index 1932231f..12664d41 100644
--- a/default/templates/layouts/note.tpl
+++ b/default/templates/layouts/note.tpl
@@ -6,7 +6,7 @@

 <apply template="base">
   <bind tag="head-main">
-    <link rel="stylesheet" href="${ema:emanoteStaticLayerUrl}/inverted-tree.css" />
+    <link rel="stylesheet" href="/${ema:emanoteStaticLayerUrl}/inverted-tree.css" />
   </bind>
   <bind tag="body-main">
     <div class="${containerClass}">