Repository navigation
In the Edge browser, the character {docsify-updated} is not replaced #2681
Description
Description
https://yequanrui.github.io/CloudNotes/#/_index
It displays correctly in the Chrome browser, with {docsify-updated} being replaced by the value of last-modified.
It is displayed incorrectly in the Edge browser. The last-modified has a value, but {docsify-updated} is not replaced.
Expected behavior
Replace with the value of last-modified.
Actual behavior
{docsify-updated} has not been replaced.
Steps to reproduce
- Check whether the value after
Last update time:is correct in the Chrome browser - Check whether the value after
Last update time:is correct in the Edge browser
Environment
- Your OS: Windows 11 25H2
- Node.js version: 20.20.0
- npm/yarn version: 10.9.4
- Browser version: Edge 145.0.3800.70 / Chrome 145.0.7632.110
- Docsify version: 4.13.1
- Docsify plugins (if the bug happens when plugins enabled, please try to isolate the issue): docsify-updated 1.0.5
Additional Information
- Bug still occurs when all/other plugins are disabled?
Activity
sy-records commentedon Apr 15, 2026
I can't reproduce it
hiSandog commentedon Jun 26, 2026
One thing that would help narrow this down is whether Edge is loading the same generated HTML and the same
last-modifiedresponse headers as Chrome after a hard refresh. Since the placeholder replacement depends on fetching/seeing that metadata, it would be useful to include the Edge version, whether any service worker/cache is involved, and a small network-panel screenshot for the markdown file request. That would separate a Docsify parsing issue from an Edge cache/header difference.yequanrui commentedon Jun 29, 2026
I found that in the Chrome browser, by adding a breakpoint to the line of code where the date is replaced, the breakpoint will take effect.
However, in the Edge browser, the breakpoint did not take effect.
AmanUllah687 commentedon Aug 4, 2026
I'd like to take this on. Traced it down to
src/core/render/index.js:opt.updatedAtcomes fromxhr.getResponseHeader('last-modified')inajax.js. This is a truthy check — if that header comes back empty in Edge for this request, the whole replace step gets skipped silently, which matches what @yequanrui described (breakpoint on the replace line never fires in Edge).Going to verify with a Network-tab comparison between Chrome and Edge to confirm whether
Last-Modifiedis actually present/absent in Edge's response headers before proposing a fix. Will follow up with findings.AmanUllah687 commentedon Aug 4, 2026
Followed up on this — built a minimal repro against current
develop(v5) using a local static server, tested in both Chrome and Edge with cache disabled to rule out stale responses. In both browsers,{docsify-updated}correctly resolves to a real date; I couldn't reproduce the Edge-specific failure described here.Since the original report was on Docsify 4.13.1, it's possible this was fixed during the v5 rewrite, or it's specific to how the CDN (GitHub Pages/Fastly) exposes response headers to Edge versus a plain local server — that's not something I can replicate locally. If it's still happening on current
develop, more detail on the hosting setup would help narrow it down.Separately, while testing this I found a real, unrelated bug: the default
formatUpdated: ''config causes{docsify-updated}to always render blank (viatinydate('')always returning an empty string), regardless of browser. Happy to open a small PR for that if useful — want me to file it as its own issue, or is a direct PR fine?sy-records commentedon Aug 4, 2026
formatUpdatedis empty by default; if you need to use it, you must set the format.AmanUllah687 commentedon Aug 4, 2026
Ah, that makes sense — thanks for clarifying. Good to know it's intentional rather than a bug.
Since the original Edge-specific issue also didn't reproduce on current
developin my testing, is it worth closing this one out, or would you prefer to leave it open in case someone can reproduce it with more specific hosting details?sy-records commentedon Aug 4, 2026
Wait for the author; I can't reproduce this issue either. @yequanrui
AmanUllah687 commentedon Aug 4, 2026
Sounds good, I'll leave this to @yequanrui to follow up with more detail.
sy-records commentedon Aug 4, 2026
This is another solution. #1157 (comment)
AmanUllah687 commentedon Aug 4, 2026
Makes sense — given #1157 was closed as not planned for essentially the same root cause (header/timestamp behavior varying by host), this looks like a known limitation rather than something fixable in Docsify's code. I'll leave this closed on my end too. Thanks for digging up the history.