@perchance@lemmy.world

I’m now coming up against the issue you thought I was having before. Where after a [code block] is processed it’s evaluated. But if using a <script> tag to do things it won’t be.

I don’t want evaluation to happen. So I could escape perchance specials to work right when returned to a code block, but they won’t be evaluated by scripts so they’ll still be there on the page. Or I could not escape perchance specials to work right from scripts, but they will be evaluated by code blocks which I don’t want. I just want plain text to always come out no matter what.

And there’s (seemingly) no way of knowing if it’s going to be evaluated at the end of a code block or not. And no way of just telling perchance “LEAVE THIS STRING ALOOOOOONE!!”

Is there anything I can do or is this just not possible in any way?

If not, I’d really super-duper like it if you could add a way. Even if it is as simple and “dumb” as setting a property on the object like .DONTEVALUATETHIS = true or something. I’d really appreciate it.

Or even something like if it has .evaluateItem = "..." it’ll automatically use that instead? Maybe? I tried that in case, and it didn’t work.

Honestly, I’m surprised this isn’t an issue for all sorts of plugins. Though maybe it is assumed that everyone only ever calls anything from code blocks and not scripts. Or people just don’t think about or have instances where the plugin returns HTML that includes specials that they want to stay plain text.

But as I’m doing my best to make my plugin bulletproof no matter how it’s used… it’s driving me insane 😅

  • wthit56@lemmy.worldOP
    link
    fedilink
    English
    arrow-up
    2
    ·
    3 months ago

    I… might have found a solution. It’s super hacky, but simple enough.

    if (!document.currentScript) {
      // escape specials
    }
    

    document.currentScript references the script tag in the DOM that is currently being processed. Or null if no script tag is being processed. Luckily somehow this works? I guess because the [code blocks] are (luckily) being processed in an event, something like that?

    Of course, this is extremely brittle, but will do for now I guess. Same as my using __evaluateText 😅

    • wthit56@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      3 months ago

      @perchance@lemmy.world Yeeeeeeeeeeah… so that wasn’t actually working. It does work when direct from a script. Doesn’t work when from an event, because it’s no longer processing the script tag itself. 🤦

      I’ve resorted to requiring the plugin user to tell me if the HTML should be escaped or not. But obviously… that suuuuuucks.

      Really hoping for some way of knowing if a code block is being processed or not. Or a way of setting my own “evaluateItem” so I can override the processing. Or a way of telling perchance not to forcibly evaluate an object.

      This issue is driving me crazy every time I find a new edge case or some hacky workaround turns out not to be working after all.

  • wthit56@lemmy.worldOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 months ago

    I can’t even use html entities because they’re converted and parsed as well 🤦 AAAAAAAAAAAAAAAARGRHRGRGHRGHJRG

  • eatham 🇭🇲@aussie.zoneM
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 months ago

    You can use a backslash before special characters to treat them as plaintext. I have an import gen which is HTML, I will link it if you want

    • wthit56@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      3 months ago

      Yes, I’ve been doing that. The issue is that my plugin allows the user of the plugin to have a function that returns html. That html is then eventually returned by the plugin.

      But depending on if it’s being called by a code block and injected that way, or being called by a script tag and being injected with .innerHTML… those backslash escapes will be stripped out, or they won’t. It behaves differently. Try it and see.

      The solution I added here in a comment works to detect it, but really it shouldn’t be necessary.