Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/webdirect-skill-discoverability.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
---
"@proofkit/webviewer": patch
---

Make webdirect-runtime skill discoverable for encoding/blank-app issues: description now leads with blank/empty WebDirect page and character encoding (UTF-8, Unicode, emoji, special characters, deploy_html) keywords; troubleshooting section names `deploy_html` and common non-ASCII culprits.
17 changes: 11 additions & 6 deletions packages/webviewer/skills/webdirect-runtime/SKILL.md
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
---
name: webdirect-runtime
description: >
FileMaker WebDirect ProofKit Web Viewer runtime behavior refresh resilience
session state localStorage browser resize reload same deployment embedded bundle
avoid separate deployment avoid separate web server @proofkit/webviewer
fmFetch callFMScript WebViewerAdapter WebDirect page refresh blank app empty body
character encoding browser network response console errors deployed HTML
Troubleshoot and build FileMaker WebDirect ProofKit Web Viewer apps. Load when a Web Viewer
app is blank, white, or empty in WebDirect, when the WebDirect page response has an empty
body, when deployed HTML is garbled, mangled, or corrupted, or when diagnosing character
encoding, UTF-8, Unicode, mojibake, emoji, accented, curly quote, or other special or
non-ASCII characters in the single-file HTML written by the deploy_html FileMaker script.
Also covers refresh resilience, unexpected page reload from browser resize, session state
in localStorage, bundle size and page-weight myths, running the same embedded bundle in
WebDirect and FileMaker Pro without a separate deployment or web server, and browser
console and network diagnosis with @proofkit/webviewer fmFetch callFMScript
WebViewerAdapter.
metadata:
type: core
library: proofkit
Expand DownExpand Up@@ -48,7 +53,7 @@ When a web app doesn't load in WebDirect, inspect what the browser received befo
3. Check the browser console for parse errors, runtime exceptions, blocked resources, or security errors.
4. Distinguish an empty WebDirect page response from an empty rendered root element inside the Web Viewer. React can start with an empty root and populate it at runtime, so the DOM alone doesn't prove that WebDirect omitted the bundle.

If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML can cause WebDirect to return an empty body instead of sending the bundle. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy, and check the full WebDirect response again.
If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML — the payload the `deploy_html` FileMaker script writes into the file — can cause WebDirect to return an empty body instead of sending the bundle. Non-ASCII content such as emoji, curly quotes, accented letters, or invalid UTF-8 sequences is the usual source. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy via `deploy_html`, and check the full WebDirect response again.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

sed -n '1,110p' packages/webviewer/skills/webdirect-runtime/SKILL.md
printf'\n--- deploy_html references ---\n'
rg -n -C 3 'deploy_html|encoding|UTF-8|empty body|WebDirect' packages/webviewer

Repository: proofsh/proofkit

Length of output: 19230


🌐 Web query:

FileMaker WebDirect empty response body unsupported character UTF-8 HTML encoding deploy HTML

💡 Result:

In FileMaker WebDirect, issues involving empty response bodies or failing to load content in Web Viewers are often related to how HTML data URIs are constructed, character encoding, or specific reserved character strings. Key technical insights for troubleshooting: 1. Data URI Encoding Strategy: Historically, developers used Base64 encoding for HTML content in Web Viewers to avoid character conflict issues in WebDirect [1][2]. The pattern involves checking the application version and applying Base64 encoding only for WebDirect: Case ( PatternCount ( Get ( ApplicationVersion); "Web"); "data:text/html;base64," & Base64Encode ( YourHTMLField); "data:text/html," & YourHTMLField) [1]. However, note that as of FileMaker Server 21.1, the requirement to use Base64 encoding for Web Viewers has been removed, and using it may now be unnecessary or even detrimental to performance [3]. 2. Special Characters and Encoding: - Reserved Characters: If your HTML or URL contains characters like '#', it can break Web Viewer rendering in certain browsers [4][2]. A common workaround is to substitute '#' with its URL-encoded equivalent '%23' for WebDirect clients [2]. - URI Syntax: Including explicit character sets like 'charset=UTF-8' within a data URI (e.g., 'data:text/html;charset=UTF-8,...') can sometimes conflict with WebDirect's internal handling of the Web Viewer, leading to rendering failures [5]. - General URL Encoding: All URL parameters (database names, script names, script parameters) must be properly URL-encoded (e.g., space to '%20') [6][7][8]. Failing to encode special characters in these strings can lead to HTTP 500 errors or broken sessions [9]. 3. Blocked Strings: FileMaker WebDirect historically blocks specific strings in Web Viewer content. For example, the string '/fmi/webd' is restricted within Web Viewer HTML source because it conflicts with the WebDirect engine itself. If you must use such strings, developers have used workarounds like RFC 3986 encoding (e.g., '/fmi/web%64') to bypass these filters [10]. 4. Troubleshooting Checklist: - Verify that your FileMaker Server deployment is up to date, as many WebDirect rendering and encoding issues have been addressed in recent versions [11][3][6]. - Test your HTML content by stripping it down to the simplest possible version to isolate if specific characters or external resources (like CSS/JS libraries) are causing the failure [1]. - Check browser console logs for "FileMaker is undefined" errors, which often indicate that the Web Viewer failed to initialize correctly due to its content [5].

Citations:


🏁 Script executed:

printf'%s\n''--- all deploy_html references ---'
rg -n -C 4 'deploy_html|Base64Encode|data:text/html|invalid UTF-8|misdecoded|unsupported character|non-ASCII'.printf'%s\n''--- UTF-8 validity of the reviewed document ---'
python3 - <<'PY'from pathlib import Pathpath = Path("packages/webviewer/skills/webdirect-runtime/SKILL.md")data = path.read_bytes()try: text = data.decode("utf-8")except UnicodeDecodeError as exc: print(f"{path}: invalid UTF-8: {exc}")else: print(f"{path}: valid UTF-8, {len(text)} characters") for term in ("emoji", "curly quotes", "accented letters", "invalid UTF-8 sequences"): print(f"{term!r}: {term in text}")PY

Repository: proofsh/proofkit

Length of output: 12985


Limit the warning to malformed or misdecoded content.

Emoji, curly quotes, and accented letters are valid UTF-8 by themselves. State that malformed or misdecoded non-ASCII content is the failure condition, including invalid UTF-8 sequences affecting those characters.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/webviewer/skills/webdirect-runtime/SKILL.md` at line 56, Update the
character-encoding guidance in the WebDirect troubleshooting section to identify
malformed or misdecoded non-ASCII content as the failure condition, rather than
listing valid emoji, curly quotes, or accented letters as inherently
problematic. Mention invalid UTF-8 sequences affecting those characters, while
preserving the existing inspection, rebuild, redeploy, and response-check steps.


If the full WebDirect response contains the Web Viewer HTML and JavaScript bundle, don't keep treating encoding or bundle size as the default cause. Follow the browser's console and network evidence to the parse, runtime, bridge, or security failure.

Expand Down
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/webdirect-skill-discoverability.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
---
"@proofkit/webviewer": patch
---

Make webdirect-runtime skill discoverable for encoding/blank-app issues: description now leads with blank/empty WebDirect page and character encoding (UTF-8, Unicode, emoji, special characters, deploy_html) keywords; troubleshooting section names `deploy_html` and common non-ASCII culprits.
17 changes: 11 additions & 6 deletions packages/webviewer/skills/webdirect-runtime/SKILL.md
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
---
name: webdirect-runtime
description: >
FileMaker WebDirect ProofKit Web Viewer runtime behavior refresh resilience
session state localStorage browser resize reload same deployment embedded bundle
avoid separate deployment avoid separate web server @proofkit/webviewer
fmFetch callFMScript WebViewerAdapter WebDirect page refresh blank app empty body
character encoding browser network response console errors deployed HTML
Troubleshoot and build FileMaker WebDirect ProofKit Web Viewer apps. Load when a Web Viewer
app is blank, white, or empty in WebDirect, when the WebDirect page response has an empty
body, when deployed HTML is garbled, mangled, or corrupted, or when diagnosing character
encoding, UTF-8, Unicode, mojibake, emoji, accented, curly quote, or other special or
non-ASCII characters in the single-file HTML written by the deploy_html FileMaker script.
Also covers refresh resilience, unexpected page reload from browser resize, session state
in localStorage, bundle size and page-weight myths, running the same embedded bundle in
WebDirect and FileMaker Pro without a separate deployment or web server, and browser
console and network diagnosis with @proofkit/webviewer fmFetch callFMScript
WebViewerAdapter.
metadata:
type: core
library: proofkit
Expand DownExpand Up@@ -48,7 +53,7 @@ When a web app doesn't load in WebDirect, inspect what the browser received befo
3. Check the browser console for parse errors, runtime exceptions, blocked resources, or security errors.
4. Distinguish an empty WebDirect page response from an empty rendered root element inside the Web Viewer. React can start with an empty root and populate it at runtime, so the DOM alone doesn't prove that WebDirect omitted the bundle.

If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML can cause WebDirect to return an empty body instead of sending the bundle. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy, and check the full WebDirect response again.
If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML — the payload the `deploy_html` FileMaker script writes into the file — can cause WebDirect to return an empty body instead of sending the bundle. Non-ASCII content such as emoji, curly quotes, accented letters, or invalid UTF-8 sequences is the usual source. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy via `deploy_html`, and check the full WebDirect response again.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

sed -n '1,110p' packages/webviewer/skills/webdirect-runtime/SKILL.md
printf'\n--- deploy_html references ---\n'
rg -n -C 3 'deploy_html|encoding|UTF-8|empty body|WebDirect' packages/webviewer

Repository: proofsh/proofkit

Length of output: 19230


🌐 Web query:

FileMaker WebDirect empty response body unsupported character UTF-8 HTML encoding deploy HTML

💡 Result:

In FileMaker WebDirect, issues involving empty response bodies or failing to load content in Web Viewers are often related to how HTML data URIs are constructed, character encoding, or specific reserved character strings. Key technical insights for troubleshooting: 1. Data URI Encoding Strategy: Historically, developers used Base64 encoding for HTML content in Web Viewers to avoid character conflict issues in WebDirect [1][2]. The pattern involves checking the application version and applying Base64 encoding only for WebDirect: Case ( PatternCount ( Get ( ApplicationVersion); "Web"); "data:text/html;base64," & Base64Encode ( YourHTMLField); "data:text/html," & YourHTMLField) [1]. However, note that as of FileMaker Server 21.1, the requirement to use Base64 encoding for Web Viewers has been removed, and using it may now be unnecessary or even detrimental to performance [3]. 2. Special Characters and Encoding: - Reserved Characters: If your HTML or URL contains characters like '#', it can break Web Viewer rendering in certain browsers [4][2]. A common workaround is to substitute '#' with its URL-encoded equivalent '%23' for WebDirect clients [2]. - URI Syntax: Including explicit character sets like 'charset=UTF-8' within a data URI (e.g., 'data:text/html;charset=UTF-8,...') can sometimes conflict with WebDirect's internal handling of the Web Viewer, leading to rendering failures [5]. - General URL Encoding: All URL parameters (database names, script names, script parameters) must be properly URL-encoded (e.g., space to '%20') [6][7][8]. Failing to encode special characters in these strings can lead to HTTP 500 errors or broken sessions [9]. 3. Blocked Strings: FileMaker WebDirect historically blocks specific strings in Web Viewer content. For example, the string '/fmi/webd' is restricted within Web Viewer HTML source because it conflicts with the WebDirect engine itself. If you must use such strings, developers have used workarounds like RFC 3986 encoding (e.g., '/fmi/web%64') to bypass these filters [10]. 4. Troubleshooting Checklist: - Verify that your FileMaker Server deployment is up to date, as many WebDirect rendering and encoding issues have been addressed in recent versions [11][3][6]. - Test your HTML content by stripping it down to the simplest possible version to isolate if specific characters or external resources (like CSS/JS libraries) are causing the failure [1]. - Check browser console logs for "FileMaker is undefined" errors, which often indicate that the Web Viewer failed to initialize correctly due to its content [5].

Citations:


🏁 Script executed:

printf'%s\n''--- all deploy_html references ---'
rg -n -C 4 'deploy_html|Base64Encode|data:text/html|invalid UTF-8|misdecoded|unsupported character|non-ASCII'.printf'%s\n''--- UTF-8 validity of the reviewed document ---'
python3 - <<'PY'from pathlib import Pathpath = Path("packages/webviewer/skills/webdirect-runtime/SKILL.md")data = path.read_bytes()try: text = data.decode("utf-8")except UnicodeDecodeError as exc: print(f"{path}: invalid UTF-8: {exc}")else: print(f"{path}: valid UTF-8, {len(text)} characters") for term in ("emoji", "curly quotes", "accented letters", "invalid UTF-8 sequences"): print(f"{term!r}: {term in text}")PY

Repository: proofsh/proofkit

Length of output: 12985


Limit the warning to malformed or misdecoded content.

Emoji, curly quotes, and accented letters are valid UTF-8 by themselves. State that malformed or misdecoded non-ASCII content is the failure condition, including invalid UTF-8 sequences affecting those characters.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/webviewer/skills/webdirect-runtime/SKILL.md` at line 56, Update the
character-encoding guidance in the WebDirect troubleshooting section to identify
malformed or misdecoded non-ASCII content as the failure condition, rather than
listing valid emoji, curly quotes, or accented letters as inherently
problematic. Mention invalid UTF-8 sequences affecting those characters, while
preserving the existing inspection, rebuild, redeploy, and response-check steps.


If the full WebDirect response contains the Web Viewer HTML and JavaScript bundle, don't keep treating encoding or bundle size as the default cause. Follow the browser's console and network evidence to the parse, runtime, bridge, or security failure.

Expand Down
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/webdirect-skill-discoverability.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
---
"@proofkit/webviewer": patch
---

Make webdirect-runtime skill discoverable for encoding/blank-app issues: description now leads with blank/empty WebDirect page and character encoding (UTF-8, Unicode, emoji, special characters, deploy_html) keywords; troubleshooting section names `deploy_html` and common non-ASCII culprits.
17 changes: 11 additions & 6 deletions packages/webviewer/skills/webdirect-runtime/SKILL.md
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
---
name: webdirect-runtime
description: >
FileMaker WebDirect ProofKit Web Viewer runtime behavior refresh resilience
session state localStorage browser resize reload same deployment embedded bundle
avoid separate deployment avoid separate web server @proofkit/webviewer
fmFetch callFMScript WebViewerAdapter WebDirect page refresh blank app empty body
character encoding browser network response console errors deployed HTML
Troubleshoot and build FileMaker WebDirect ProofKit Web Viewer apps. Load when a Web Viewer
app is blank, white, or empty in WebDirect, when the WebDirect page response has an empty
body, when deployed HTML is garbled, mangled, or corrupted, or when diagnosing character
encoding, UTF-8, Unicode, mojibake, emoji, accented, curly quote, or other special or
non-ASCII characters in the single-file HTML written by the deploy_html FileMaker script.
Also covers refresh resilience, unexpected page reload from browser resize, session state
in localStorage, bundle size and page-weight myths, running the same embedded bundle in
WebDirect and FileMaker Pro without a separate deployment or web server, and browser
console and network diagnosis with @proofkit/webviewer fmFetch callFMScript
WebViewerAdapter.
metadata:
type: core
library: proofkit
Expand DownExpand Up@@ -48,7 +53,7 @@ When a web app doesn't load in WebDirect, inspect what the browser received befo
3. Check the browser console for parse errors, runtime exceptions, blocked resources, or security errors.
4. Distinguish an empty WebDirect page response from an empty rendered root element inside the Web Viewer. React can start with an empty root and populate it at runtime, so the DOM alone doesn't prove that WebDirect omitted the bundle.

If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML can cause WebDirect to return an empty body instead of sending the bundle. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy, and check the full WebDirect response again.
If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML — the payload the `deploy_html` FileMaker script writes into the file — can cause WebDirect to return an empty body instead of sending the bundle. Non-ASCII content such as emoji, curly quotes, accented letters, or invalid UTF-8 sequences is the usual source. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy via `deploy_html`, and check the full WebDirect response again.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

sed -n '1,110p' packages/webviewer/skills/webdirect-runtime/SKILL.md
printf'\n--- deploy_html references ---\n'
rg -n -C 3 'deploy_html|encoding|UTF-8|empty body|WebDirect' packages/webviewer

Repository: proofsh/proofkit

Length of output: 19230


🌐 Web query:

FileMaker WebDirect empty response body unsupported character UTF-8 HTML encoding deploy HTML

💡 Result:

In FileMaker WebDirect, issues involving empty response bodies or failing to load content in Web Viewers are often related to how HTML data URIs are constructed, character encoding, or specific reserved character strings. Key technical insights for troubleshooting: 1. Data URI Encoding Strategy: Historically, developers used Base64 encoding for HTML content in Web Viewers to avoid character conflict issues in WebDirect [1][2]. The pattern involves checking the application version and applying Base64 encoding only for WebDirect: Case ( PatternCount ( Get ( ApplicationVersion); "Web"); "data:text/html;base64," & Base64Encode ( YourHTMLField); "data:text/html," & YourHTMLField) [1]. However, note that as of FileMaker Server 21.1, the requirement to use Base64 encoding for Web Viewers has been removed, and using it may now be unnecessary or even detrimental to performance [3]. 2. Special Characters and Encoding: - Reserved Characters: If your HTML or URL contains characters like '#', it can break Web Viewer rendering in certain browsers [4][2]. A common workaround is to substitute '#' with its URL-encoded equivalent '%23' for WebDirect clients [2]. - URI Syntax: Including explicit character sets like 'charset=UTF-8' within a data URI (e.g., 'data:text/html;charset=UTF-8,...') can sometimes conflict with WebDirect's internal handling of the Web Viewer, leading to rendering failures [5]. - General URL Encoding: All URL parameters (database names, script names, script parameters) must be properly URL-encoded (e.g., space to '%20') [6][7][8]. Failing to encode special characters in these strings can lead to HTTP 500 errors or broken sessions [9]. 3. Blocked Strings: FileMaker WebDirect historically blocks specific strings in Web Viewer content. For example, the string '/fmi/webd' is restricted within Web Viewer HTML source because it conflicts with the WebDirect engine itself. If you must use such strings, developers have used workarounds like RFC 3986 encoding (e.g., '/fmi/web%64') to bypass these filters [10]. 4. Troubleshooting Checklist: - Verify that your FileMaker Server deployment is up to date, as many WebDirect rendering and encoding issues have been addressed in recent versions [11][3][6]. - Test your HTML content by stripping it down to the simplest possible version to isolate if specific characters or external resources (like CSS/JS libraries) are causing the failure [1]. - Check browser console logs for "FileMaker is undefined" errors, which often indicate that the Web Viewer failed to initialize correctly due to its content [5].

Citations:


🏁 Script executed:

printf'%s\n''--- all deploy_html references ---'
rg -n -C 4 'deploy_html|Base64Encode|data:text/html|invalid UTF-8|misdecoded|unsupported character|non-ASCII'.printf'%s\n''--- UTF-8 validity of the reviewed document ---'
python3 - <<'PY'from pathlib import Pathpath = Path("packages/webviewer/skills/webdirect-runtime/SKILL.md")data = path.read_bytes()try: text = data.decode("utf-8")except UnicodeDecodeError as exc: print(f"{path}: invalid UTF-8: {exc}")else: print(f"{path}: valid UTF-8, {len(text)} characters") for term in ("emoji", "curly quotes", "accented letters", "invalid UTF-8 sequences"): print(f"{term!r}: {term in text}")PY

Repository: proofsh/proofkit

Length of output: 12985


Limit the warning to malformed or misdecoded content.

Emoji, curly quotes, and accented letters are valid UTF-8 by themselves. State that malformed or misdecoded non-ASCII content is the failure condition, including invalid UTF-8 sequences affecting those characters.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/webviewer/skills/webdirect-runtime/SKILL.md` at line 56, Update the
character-encoding guidance in the WebDirect troubleshooting section to identify
malformed or misdecoded non-ASCII content as the failure condition, rather than
listing valid emoji, curly quotes, or accented letters as inherently
problematic. Mention invalid UTF-8 sequences affecting those characters, while
preserving the existing inspection, rebuild, redeploy, and response-check steps.


If the full WebDirect response contains the Web Viewer HTML and JavaScript bundle, don't keep treating encoding or bundle size as the default cause. Follow the browser's console and network evidence to the parse, runtime, bridge, or security failure.

Expand Down
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/webdirect-skill-discoverability.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
---
"@proofkit/webviewer": patch
---

Make webdirect-runtime skill discoverable for encoding/blank-app issues: description now leads with blank/empty WebDirect page and character encoding (UTF-8, Unicode, emoji, special characters, deploy_html) keywords; troubleshooting section names `deploy_html` and common non-ASCII culprits.
17 changes: 11 additions & 6 deletions packages/webviewer/skills/webdirect-runtime/SKILL.md
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
---
name: webdirect-runtime
description: >
FileMaker WebDirect ProofKit Web Viewer runtime behavior refresh resilience
session state localStorage browser resize reload same deployment embedded bundle
avoid separate deployment avoid separate web server @proofkit/webviewer
fmFetch callFMScript WebViewerAdapter WebDirect page refresh blank app empty body
character encoding browser network response console errors deployed HTML
Troubleshoot and build FileMaker WebDirect ProofKit Web Viewer apps. Load when a Web Viewer
app is blank, white, or empty in WebDirect, when the WebDirect page response has an empty
body, when deployed HTML is garbled, mangled, or corrupted, or when diagnosing character
encoding, UTF-8, Unicode, mojibake, emoji, accented, curly quote, or other special or
non-ASCII characters in the single-file HTML written by the deploy_html FileMaker script.
Also covers refresh resilience, unexpected page reload from browser resize, session state
in localStorage, bundle size and page-weight myths, running the same embedded bundle in
WebDirect and FileMaker Pro without a separate deployment or web server, and browser
console and network diagnosis with @proofkit/webviewer fmFetch callFMScript
WebViewerAdapter.
metadata:
type: core
library: proofkit
Expand DownExpand Up@@ -48,7 +53,7 @@ When a web app doesn't load in WebDirect, inspect what the browser received befo
3. Check the browser console for parse errors, runtime exceptions, blocked resources, or security errors.
4. Distinguish an empty WebDirect page response from an empty rendered root element inside the Web Viewer. React can start with an empty root and populate it at runtime, so the DOM alone doesn't prove that WebDirect omitted the bundle.

If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML can cause WebDirect to return an empty body instead of sending the bundle. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy, and check the full WebDirect response again.
If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML — the payload the `deploy_html` FileMaker script writes into the file — can cause WebDirect to return an empty body instead of sending the bundle. Non-ASCII content such as emoji, curly quotes, accented letters, or invalid UTF-8 sequences is the usual source. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy via `deploy_html`, and check the full WebDirect response again.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

sed -n '1,110p' packages/webviewer/skills/webdirect-runtime/SKILL.md
printf'\n--- deploy_html references ---\n'
rg -n -C 3 'deploy_html|encoding|UTF-8|empty body|WebDirect' packages/webviewer

Repository: proofsh/proofkit

Length of output: 19230


🌐 Web query:

FileMaker WebDirect empty response body unsupported character UTF-8 HTML encoding deploy HTML

💡 Result:

In FileMaker WebDirect, issues involving empty response bodies or failing to load content in Web Viewers are often related to how HTML data URIs are constructed, character encoding, or specific reserved character strings. Key technical insights for troubleshooting: 1. Data URI Encoding Strategy: Historically, developers used Base64 encoding for HTML content in Web Viewers to avoid character conflict issues in WebDirect [1][2]. The pattern involves checking the application version and applying Base64 encoding only for WebDirect: Case ( PatternCount ( Get ( ApplicationVersion); "Web"); "data:text/html;base64," & Base64Encode ( YourHTMLField); "data:text/html," & YourHTMLField) [1]. However, note that as of FileMaker Server 21.1, the requirement to use Base64 encoding for Web Viewers has been removed, and using it may now be unnecessary or even detrimental to performance [3]. 2. Special Characters and Encoding: - Reserved Characters: If your HTML or URL contains characters like '#', it can break Web Viewer rendering in certain browsers [4][2]. A common workaround is to substitute '#' with its URL-encoded equivalent '%23' for WebDirect clients [2]. - URI Syntax: Including explicit character sets like 'charset=UTF-8' within a data URI (e.g., 'data:text/html;charset=UTF-8,...') can sometimes conflict with WebDirect's internal handling of the Web Viewer, leading to rendering failures [5]. - General URL Encoding: All URL parameters (database names, script names, script parameters) must be properly URL-encoded (e.g., space to '%20') [6][7][8]. Failing to encode special characters in these strings can lead to HTTP 500 errors or broken sessions [9]. 3. Blocked Strings: FileMaker WebDirect historically blocks specific strings in Web Viewer content. For example, the string '/fmi/webd' is restricted within Web Viewer HTML source because it conflicts with the WebDirect engine itself. If you must use such strings, developers have used workarounds like RFC 3986 encoding (e.g., '/fmi/web%64') to bypass these filters [10]. 4. Troubleshooting Checklist: - Verify that your FileMaker Server deployment is up to date, as many WebDirect rendering and encoding issues have been addressed in recent versions [11][3][6]. - Test your HTML content by stripping it down to the simplest possible version to isolate if specific characters or external resources (like CSS/JS libraries) are causing the failure [1]. - Check browser console logs for "FileMaker is undefined" errors, which often indicate that the Web Viewer failed to initialize correctly due to its content [5].

Citations:


🏁 Script executed:

printf'%s\n''--- all deploy_html references ---'
rg -n -C 4 'deploy_html|Base64Encode|data:text/html|invalid UTF-8|misdecoded|unsupported character|non-ASCII'.printf'%s\n''--- UTF-8 validity of the reviewed document ---'
python3 - <<'PY'from pathlib import Pathpath = Path("packages/webviewer/skills/webdirect-runtime/SKILL.md")data = path.read_bytes()try: text = data.decode("utf-8")except UnicodeDecodeError as exc: print(f"{path}: invalid UTF-8: {exc}")else: print(f"{path}: valid UTF-8, {len(text)} characters") for term in ("emoji", "curly quotes", "accented letters", "invalid UTF-8 sequences"): print(f"{term!r}: {term in text}")PY

Repository: proofsh/proofkit

Length of output: 12985


Limit the warning to malformed or misdecoded content.

Emoji, curly quotes, and accented letters are valid UTF-8 by themselves. State that malformed or misdecoded non-ASCII content is the failure condition, including invalid UTF-8 sequences affecting those characters.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/webviewer/skills/webdirect-runtime/SKILL.md` at line 56, Update the
character-encoding guidance in the WebDirect troubleshooting section to identify
malformed or misdecoded non-ASCII content as the failure condition, rather than
listing valid emoji, curly quotes, or accented letters as inherently
problematic. Mention invalid UTF-8 sequences affecting those characters, while
preserving the existing inspection, rebuild, redeploy, and response-check steps.


If the full WebDirect response contains the Web Viewer HTML and JavaScript bundle, don't keep treating encoding or bundle size as the default cause. Follow the browser's console and network evidence to the parse, runtime, bridge, or security failure.

Expand Down
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/webdirect-skill-discoverability.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
---
"@proofkit/webviewer": patch
---

Make webdirect-runtime skill discoverable for encoding/blank-app issues: description now leads with blank/empty WebDirect page and character encoding (UTF-8, Unicode, emoji, special characters, deploy_html) keywords; troubleshooting section names `deploy_html` and common non-ASCII culprits.
17 changes: 11 additions & 6 deletions packages/webviewer/skills/webdirect-runtime/SKILL.md
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
---
name: webdirect-runtime
description: >
FileMaker WebDirect ProofKit Web Viewer runtime behavior refresh resilience
session state localStorage browser resize reload same deployment embedded bundle
avoid separate deployment avoid separate web server @proofkit/webviewer
fmFetch callFMScript WebViewerAdapter WebDirect page refresh blank app empty body
character encoding browser network response console errors deployed HTML
Troubleshoot and build FileMaker WebDirect ProofKit Web Viewer apps. Load when a Web Viewer
app is blank, white, or empty in WebDirect, when the WebDirect page response has an empty
body, when deployed HTML is garbled, mangled, or corrupted, or when diagnosing character
encoding, UTF-8, Unicode, mojibake, emoji, accented, curly quote, or other special or
non-ASCII characters in the single-file HTML written by the deploy_html FileMaker script.
Also covers refresh resilience, unexpected page reload from browser resize, session state
in localStorage, bundle size and page-weight myths, running the same embedded bundle in
WebDirect and FileMaker Pro without a separate deployment or web server, and browser
console and network diagnosis with @proofkit/webviewer fmFetch callFMScript
WebViewerAdapter.
metadata:
type: core
library: proofkit
Expand DownExpand Up@@ -48,7 +53,7 @@ When a web app doesn't load in WebDirect, inspect what the browser received befo
3. Check the browser console for parse errors, runtime exceptions, blocked resources, or security errors.
4. Distinguish an empty WebDirect page response from an empty rendered root element inside the Web Viewer. React can start with an empty root and populate it at runtime, so the DOM alone doesn't prove that WebDirect omitted the bundle.

If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML can cause WebDirect to return an empty body instead of sending the bundle. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy, and check the full WebDirect response again.
If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML — the payload the `deploy_html` FileMaker script writes into the file — can cause WebDirect to return an empty body instead of sending the bundle. Non-ASCII content such as emoji, curly quotes, accented letters, or invalid UTF-8 sequences is the usual source. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy via `deploy_html`, and check the full WebDirect response again.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

sed -n '1,110p' packages/webviewer/skills/webdirect-runtime/SKILL.md
printf'\n--- deploy_html references ---\n'
rg -n -C 3 'deploy_html|encoding|UTF-8|empty body|WebDirect' packages/webviewer

Repository: proofsh/proofkit

Length of output: 19230


🌐 Web query:

FileMaker WebDirect empty response body unsupported character UTF-8 HTML encoding deploy HTML

💡 Result:

In FileMaker WebDirect, issues involving empty response bodies or failing to load content in Web Viewers are often related to how HTML data URIs are constructed, character encoding, or specific reserved character strings. Key technical insights for troubleshooting: 1. Data URI Encoding Strategy: Historically, developers used Base64 encoding for HTML content in Web Viewers to avoid character conflict issues in WebDirect [1][2]. The pattern involves checking the application version and applying Base64 encoding only for WebDirect: Case ( PatternCount ( Get ( ApplicationVersion); "Web"); "data:text/html;base64," & Base64Encode ( YourHTMLField); "data:text/html," & YourHTMLField) [1]. However, note that as of FileMaker Server 21.1, the requirement to use Base64 encoding for Web Viewers has been removed, and using it may now be unnecessary or even detrimental to performance [3]. 2. Special Characters and Encoding: - Reserved Characters: If your HTML or URL contains characters like '#', it can break Web Viewer rendering in certain browsers [4][2]. A common workaround is to substitute '#' with its URL-encoded equivalent '%23' for WebDirect clients [2]. - URI Syntax: Including explicit character sets like 'charset=UTF-8' within a data URI (e.g., 'data:text/html;charset=UTF-8,...') can sometimes conflict with WebDirect's internal handling of the Web Viewer, leading to rendering failures [5]. - General URL Encoding: All URL parameters (database names, script names, script parameters) must be properly URL-encoded (e.g., space to '%20') [6][7][8]. Failing to encode special characters in these strings can lead to HTTP 500 errors or broken sessions [9]. 3. Blocked Strings: FileMaker WebDirect historically blocks specific strings in Web Viewer content. For example, the string '/fmi/webd' is restricted within Web Viewer HTML source because it conflicts with the WebDirect engine itself. If you must use such strings, developers have used workarounds like RFC 3986 encoding (e.g., '/fmi/web%64') to bypass these filters [10]. 4. Troubleshooting Checklist: - Verify that your FileMaker Server deployment is up to date, as many WebDirect rendering and encoding issues have been addressed in recent versions [11][3][6]. - Test your HTML content by stripping it down to the simplest possible version to isolate if specific characters or external resources (like CSS/JS libraries) are causing the failure [1]. - Check browser console logs for "FileMaker is undefined" errors, which often indicate that the Web Viewer failed to initialize correctly due to its content [5].

Citations:


🏁 Script executed:

printf'%s\n''--- all deploy_html references ---'
rg -n -C 4 'deploy_html|Base64Encode|data:text/html|invalid UTF-8|misdecoded|unsupported character|non-ASCII'.printf'%s\n''--- UTF-8 validity of the reviewed document ---'
python3 - <<'PY'from pathlib import Pathpath = Path("packages/webviewer/skills/webdirect-runtime/SKILL.md")data = path.read_bytes()try: text = data.decode("utf-8")except UnicodeDecodeError as exc: print(f"{path}: invalid UTF-8: {exc}")else: print(f"{path}: valid UTF-8, {len(text)} characters") for term in ("emoji", "curly quotes", "accented letters", "invalid UTF-8 sequences"): print(f"{term!r}: {term in text}")PY

Repository: proofsh/proofkit

Length of output: 12985


Limit the warning to malformed or misdecoded content.

Emoji, curly quotes, and accented letters are valid UTF-8 by themselves. State that malformed or misdecoded non-ASCII content is the failure condition, including invalid UTF-8 sequences affecting those characters.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/webviewer/skills/webdirect-runtime/SKILL.md` at line 56, Update the
character-encoding guidance in the WebDirect troubleshooting section to identify
malformed or misdecoded non-ASCII content as the failure condition, rather than
listing valid emoji, curly quotes, or accented letters as inherently
problematic. Mention invalid UTF-8 sequences affecting those characters, while
preserving the existing inspection, rebuild, redeploy, and response-check steps.


If the full WebDirect response contains the Web Viewer HTML and JavaScript bundle, don't keep treating encoding or bundle size as the default cause. Follow the browser's console and network evidence to the parse, runtime, bridge, or security failure.

Expand Down
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/webdirect-skill-discoverability.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
---
"@proofkit/webviewer": patch
---

Make webdirect-runtime skill discoverable for encoding/blank-app issues: description now leads with blank/empty WebDirect page and character encoding (UTF-8, Unicode, emoji, special characters, deploy_html) keywords; troubleshooting section names `deploy_html` and common non-ASCII culprits.
17 changes: 11 additions & 6 deletions packages/webviewer/skills/webdirect-runtime/SKILL.md
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
---
name: webdirect-runtime
description: >
FileMaker WebDirect ProofKit Web Viewer runtime behavior refresh resilience
session state localStorage browser resize reload same deployment embedded bundle
avoid separate deployment avoid separate web server @proofkit/webviewer
fmFetch callFMScript WebViewerAdapter WebDirect page refresh blank app empty body
character encoding browser network response console errors deployed HTML
Troubleshoot and build FileMaker WebDirect ProofKit Web Viewer apps. Load when a Web Viewer
app is blank, white, or empty in WebDirect, when the WebDirect page response has an empty
body, when deployed HTML is garbled, mangled, or corrupted, or when diagnosing character
encoding, UTF-8, Unicode, mojibake, emoji, accented, curly quote, or other special or
non-ASCII characters in the single-file HTML written by the deploy_html FileMaker script.
Also covers refresh resilience, unexpected page reload from browser resize, session state
in localStorage, bundle size and page-weight myths, running the same embedded bundle in
WebDirect and FileMaker Pro without a separate deployment or web server, and browser
console and network diagnosis with @proofkit/webviewer fmFetch callFMScript
WebViewerAdapter.
metadata:
type: core
library: proofkit
Expand DownExpand Up@@ -48,7 +53,7 @@ When a web app doesn't load in WebDirect, inspect what the browser received befo
3. Check the browser console for parse errors, runtime exceptions, blocked resources, or security errors.
4. Distinguish an empty WebDirect page response from an empty rendered root element inside the Web Viewer. React can start with an empty root and populate it at runtime, so the DOM alone doesn't prove that WebDirect omitted the bundle.

If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML can cause WebDirect to return an empty body instead of sending the bundle. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy, and check the full WebDirect response again.
If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML — the payload the `deploy_html` FileMaker script writes into the file — can cause WebDirect to return an empty body instead of sending the bundle. Non-ASCII content such as emoji, curly quotes, accented letters, or invalid UTF-8 sequences is the usual source. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy via `deploy_html`, and check the full WebDirect response again.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

sed -n '1,110p' packages/webviewer/skills/webdirect-runtime/SKILL.md
printf'\n--- deploy_html references ---\n'
rg -n -C 3 'deploy_html|encoding|UTF-8|empty body|WebDirect' packages/webviewer

Repository: proofsh/proofkit

Length of output: 19230


🌐 Web query:

FileMaker WebDirect empty response body unsupported character UTF-8 HTML encoding deploy HTML

💡 Result:

In FileMaker WebDirect, issues involving empty response bodies or failing to load content in Web Viewers are often related to how HTML data URIs are constructed, character encoding, or specific reserved character strings. Key technical insights for troubleshooting: 1. Data URI Encoding Strategy: Historically, developers used Base64 encoding for HTML content in Web Viewers to avoid character conflict issues in WebDirect [1][2]. The pattern involves checking the application version and applying Base64 encoding only for WebDirect: Case ( PatternCount ( Get ( ApplicationVersion); "Web"); "data:text/html;base64," & Base64Encode ( YourHTMLField); "data:text/html," & YourHTMLField) [1]. However, note that as of FileMaker Server 21.1, the requirement to use Base64 encoding for Web Viewers has been removed, and using it may now be unnecessary or even detrimental to performance [3]. 2. Special Characters and Encoding: - Reserved Characters: If your HTML or URL contains characters like '#', it can break Web Viewer rendering in certain browsers [4][2]. A common workaround is to substitute '#' with its URL-encoded equivalent '%23' for WebDirect clients [2]. - URI Syntax: Including explicit character sets like 'charset=UTF-8' within a data URI (e.g., 'data:text/html;charset=UTF-8,...') can sometimes conflict with WebDirect's internal handling of the Web Viewer, leading to rendering failures [5]. - General URL Encoding: All URL parameters (database names, script names, script parameters) must be properly URL-encoded (e.g., space to '%20') [6][7][8]. Failing to encode special characters in these strings can lead to HTTP 500 errors or broken sessions [9]. 3. Blocked Strings: FileMaker WebDirect historically blocks specific strings in Web Viewer content. For example, the string '/fmi/webd' is restricted within Web Viewer HTML source because it conflicts with the WebDirect engine itself. If you must use such strings, developers have used workarounds like RFC 3986 encoding (e.g., '/fmi/web%64') to bypass these filters [10]. 4. Troubleshooting Checklist: - Verify that your FileMaker Server deployment is up to date, as many WebDirect rendering and encoding issues have been addressed in recent versions [11][3][6]. - Test your HTML content by stripping it down to the simplest possible version to isolate if specific characters or external resources (like CSS/JS libraries) are causing the failure [1]. - Check browser console logs for "FileMaker is undefined" errors, which often indicate that the Web Viewer failed to initialize correctly due to its content [5].

Citations:


🏁 Script executed:

printf'%s\n''--- all deploy_html references ---'
rg -n -C 4 'deploy_html|Base64Encode|data:text/html|invalid UTF-8|misdecoded|unsupported character|non-ASCII'.printf'%s\n''--- UTF-8 validity of the reviewed document ---'
python3 - <<'PY'from pathlib import Pathpath = Path("packages/webviewer/skills/webdirect-runtime/SKILL.md")data = path.read_bytes()try: text = data.decode("utf-8")except UnicodeDecodeError as exc: print(f"{path}: invalid UTF-8: {exc}")else: print(f"{path}: valid UTF-8, {len(text)} characters") for term in ("emoji", "curly quotes", "accented letters", "invalid UTF-8 sequences"): print(f"{term!r}: {term in text}")PY

Repository: proofsh/proofkit

Length of output: 12985


Limit the warning to malformed or misdecoded content.

Emoji, curly quotes, and accented letters are valid UTF-8 by themselves. State that malformed or misdecoded non-ASCII content is the failure condition, including invalid UTF-8 sequences affecting those characters.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/webviewer/skills/webdirect-runtime/SKILL.md` at line 56, Update the
character-encoding guidance in the WebDirect troubleshooting section to identify
malformed or misdecoded non-ASCII content as the failure condition, rather than
listing valid emoji, curly quotes, or accented letters as inherently
problematic. Mention invalid UTF-8 sequences affecting those characters, while
preserving the existing inspection, rebuild, redeploy, and response-check steps.


If the full WebDirect response contains the Web Viewer HTML and JavaScript bundle, don't keep treating encoding or bundle size as the default cause. Follow the browser's console and network evidence to the parse, runtime, bridge, or security failure.

Expand Down
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/webdirect-skill-discoverability.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
---
"@proofkit/webviewer": patch
---

Make webdirect-runtime skill discoverable for encoding/blank-app issues: description now leads with blank/empty WebDirect page and character encoding (UTF-8, Unicode, emoji, special characters, deploy_html) keywords; troubleshooting section names `deploy_html` and common non-ASCII culprits.
17 changes: 11 additions & 6 deletions packages/webviewer/skills/webdirect-runtime/SKILL.md
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
---
name: webdirect-runtime
description: >
FileMaker WebDirect ProofKit Web Viewer runtime behavior refresh resilience
session state localStorage browser resize reload same deployment embedded bundle
avoid separate deployment avoid separate web server @proofkit/webviewer
fmFetch callFMScript WebViewerAdapter WebDirect page refresh blank app empty body
character encoding browser network response console errors deployed HTML
Troubleshoot and build FileMaker WebDirect ProofKit Web Viewer apps. Load when a Web Viewer
app is blank, white, or empty in WebDirect, when the WebDirect page response has an empty
body, when deployed HTML is garbled, mangled, or corrupted, or when diagnosing character
encoding, UTF-8, Unicode, mojibake, emoji, accented, curly quote, or other special or
non-ASCII characters in the single-file HTML written by the deploy_html FileMaker script.
Also covers refresh resilience, unexpected page reload from browser resize, session state
in localStorage, bundle size and page-weight myths, running the same embedded bundle in
WebDirect and FileMaker Pro without a separate deployment or web server, and browser
console and network diagnosis with @proofkit/webviewer fmFetch callFMScript
WebViewerAdapter.
metadata:
type: core
library: proofkit
Expand DownExpand Up@@ -48,7 +53,7 @@ When a web app doesn't load in WebDirect, inspect what the browser received befo
3. Check the browser console for parse errors, runtime exceptions, blocked resources, or security errors.
4. Distinguish an empty WebDirect page response from an empty rendered root element inside the Web Viewer. React can start with an empty root and populate it at runtime, so the DOM alone doesn't prove that WebDirect omitted the bundle.

If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML can cause WebDirect to return an empty body instead of sending the bundle. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy, and check the full WebDirect response again.
If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML — the payload the `deploy_html` FileMaker script writes into the file — can cause WebDirect to return an empty body instead of sending the bundle. Non-ASCII content such as emoji, curly quotes, accented letters, or invalid UTF-8 sequences is the usual source. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy via `deploy_html`, and check the full WebDirect response again.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

sed -n '1,110p' packages/webviewer/skills/webdirect-runtime/SKILL.md
printf'\n--- deploy_html references ---\n'
rg -n -C 3 'deploy_html|encoding|UTF-8|empty body|WebDirect' packages/webviewer

Repository: proofsh/proofkit

Length of output: 19230


🌐 Web query:

FileMaker WebDirect empty response body unsupported character UTF-8 HTML encoding deploy HTML

💡 Result:

In FileMaker WebDirect, issues involving empty response bodies or failing to load content in Web Viewers are often related to how HTML data URIs are constructed, character encoding, or specific reserved character strings. Key technical insights for troubleshooting: 1. Data URI Encoding Strategy: Historically, developers used Base64 encoding for HTML content in Web Viewers to avoid character conflict issues in WebDirect [1][2]. The pattern involves checking the application version and applying Base64 encoding only for WebDirect: Case ( PatternCount ( Get ( ApplicationVersion); "Web"); "data:text/html;base64," & Base64Encode ( YourHTMLField); "data:text/html," & YourHTMLField) [1]. However, note that as of FileMaker Server 21.1, the requirement to use Base64 encoding for Web Viewers has been removed, and using it may now be unnecessary or even detrimental to performance [3]. 2. Special Characters and Encoding: - Reserved Characters: If your HTML or URL contains characters like '#', it can break Web Viewer rendering in certain browsers [4][2]. A common workaround is to substitute '#' with its URL-encoded equivalent '%23' for WebDirect clients [2]. - URI Syntax: Including explicit character sets like 'charset=UTF-8' within a data URI (e.g., 'data:text/html;charset=UTF-8,...') can sometimes conflict with WebDirect's internal handling of the Web Viewer, leading to rendering failures [5]. - General URL Encoding: All URL parameters (database names, script names, script parameters) must be properly URL-encoded (e.g., space to '%20') [6][7][8]. Failing to encode special characters in these strings can lead to HTTP 500 errors or broken sessions [9]. 3. Blocked Strings: FileMaker WebDirect historically blocks specific strings in Web Viewer content. For example, the string '/fmi/webd' is restricted within Web Viewer HTML source because it conflicts with the WebDirect engine itself. If you must use such strings, developers have used workarounds like RFC 3986 encoding (e.g., '/fmi/web%64') to bypass these filters [10]. 4. Troubleshooting Checklist: - Verify that your FileMaker Server deployment is up to date, as many WebDirect rendering and encoding issues have been addressed in recent versions [11][3][6]. - Test your HTML content by stripping it down to the simplest possible version to isolate if specific characters or external resources (like CSS/JS libraries) are causing the failure [1]. - Check browser console logs for "FileMaker is undefined" errors, which often indicate that the Web Viewer failed to initialize correctly due to its content [5].

Citations:


🏁 Script executed:

printf'%s\n''--- all deploy_html references ---'
rg -n -C 4 'deploy_html|Base64Encode|data:text/html|invalid UTF-8|misdecoded|unsupported character|non-ASCII'.printf'%s\n''--- UTF-8 validity of the reviewed document ---'
python3 - <<'PY'from pathlib import Pathpath = Path("packages/webviewer/skills/webdirect-runtime/SKILL.md")data = path.read_bytes()try: text = data.decode("utf-8")except UnicodeDecodeError as exc: print(f"{path}: invalid UTF-8: {exc}")else: print(f"{path}: valid UTF-8, {len(text)} characters") for term in ("emoji", "curly quotes", "accented letters", "invalid UTF-8 sequences"): print(f"{term!r}: {term in text}")PY

Repository: proofsh/proofkit

Length of output: 12985


Limit the warning to malformed or misdecoded content.

Emoji, curly quotes, and accented letters are valid UTF-8 by themselves. State that malformed or misdecoded non-ASCII content is the failure condition, including invalid UTF-8 sequences affecting those characters.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/webviewer/skills/webdirect-runtime/SKILL.md` at line 56, Update the
character-encoding guidance in the WebDirect troubleshooting section to identify
malformed or misdecoded non-ASCII content as the failure condition, rather than
listing valid emoji, curly quotes, or accented letters as inherently
problematic. Mention invalid UTF-8 sequences affecting those characters, while
preserving the existing inspection, rebuild, redeploy, and response-check steps.


If the full WebDirect response contains the Web Viewer HTML and JavaScript bundle, don't keep treating encoding or bundle size as the default cause. Follow the browser's console and network evidence to the parse, runtime, bridge, or security failure.

Expand Down
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/webdirect-skill-discoverability.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
---
"@proofkit/webviewer": patch
---

Make webdirect-runtime skill discoverable for encoding/blank-app issues: description now leads with blank/empty WebDirect page and character encoding (UTF-8, Unicode, emoji, special characters, deploy_html) keywords; troubleshooting section names `deploy_html` and common non-ASCII culprits.
17 changes: 11 additions & 6 deletions packages/webviewer/skills/webdirect-runtime/SKILL.md
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
---
name: webdirect-runtime
description: >
FileMaker WebDirect ProofKit Web Viewer runtime behavior refresh resilience
session state localStorage browser resize reload same deployment embedded bundle
avoid separate deployment avoid separate web server @proofkit/webviewer
fmFetch callFMScript WebViewerAdapter WebDirect page refresh blank app empty body
character encoding browser network response console errors deployed HTML
Troubleshoot and build FileMaker WebDirect ProofKit Web Viewer apps. Load when a Web Viewer
app is blank, white, or empty in WebDirect, when the WebDirect page response has an empty
body, when deployed HTML is garbled, mangled, or corrupted, or when diagnosing character
encoding, UTF-8, Unicode, mojibake, emoji, accented, curly quote, or other special or
non-ASCII characters in the single-file HTML written by the deploy_html FileMaker script.
Also covers refresh resilience, unexpected page reload from browser resize, session state
in localStorage, bundle size and page-weight myths, running the same embedded bundle in
WebDirect and FileMaker Pro without a separate deployment or web server, and browser
console and network diagnosis with @proofkit/webviewer fmFetch callFMScript
WebViewerAdapter.
metadata:
type: core
library: proofkit
Expand DownExpand Up@@ -48,7 +53,7 @@ When a web app doesn't load in WebDirect, inspect what the browser received befo
3. Check the browser console for parse errors, runtime exceptions, blocked resources, or security errors.
4. Distinguish an empty WebDirect page response from an empty rendered root element inside the Web Viewer. React can start with an empty root and populate it at runtime, so the DOM alone doesn't prove that WebDirect omitted the bundle.

If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML can cause WebDirect to return an empty body instead of sending the bundle. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy, and check the full WebDirect response again.
If the complete page served by WebDirect has an empty body and the Web Viewer bundle is absent from that response, suspect character encoding first. An incorrectly encoded or unsupported character in the deployed single-file HTML — the payload the `deploy_html` FileMaker script writes into the file — can cause WebDirect to return an empty body instead of sending the bundle. Non-ASCII content such as emoji, curly quotes, accented letters, or invalid UTF-8 sequences is the usual source. Inspect the built HTML for invalid UTF-8 or problematic characters, rebuild, redeploy via `deploy_html`, and check the full WebDirect response again.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

sed -n '1,110p' packages/webviewer/skills/webdirect-runtime/SKILL.md
printf'\n--- deploy_html references ---\n'
rg -n -C 3 'deploy_html|encoding|UTF-8|empty body|WebDirect' packages/webviewer

Repository: proofsh/proofkit

Length of output: 19230


🌐 Web query:

FileMaker WebDirect empty response body unsupported character UTF-8 HTML encoding deploy HTML

💡 Result:

In FileMaker WebDirect, issues involving empty response bodies or failing to load content in Web Viewers are often related to how HTML data URIs are constructed, character encoding, or specific reserved character strings. Key technical insights for troubleshooting: 1. Data URI Encoding Strategy: Historically, developers used Base64 encoding for HTML content in Web Viewers to avoid character conflict issues in WebDirect [1][2]. The pattern involves checking the application version and applying Base64 encoding only for WebDirect: Case ( PatternCount ( Get ( ApplicationVersion); "Web"); "data:text/html;base64," & Base64Encode ( YourHTMLField); "data:text/html," & YourHTMLField) [1]. However, note that as of FileMaker Server 21.1, the requirement to use Base64 encoding for Web Viewers has been removed, and using it may now be unnecessary or even detrimental to performance [3]. 2. Special Characters and Encoding: - Reserved Characters: If your HTML or URL contains characters like '#', it can break Web Viewer rendering in certain browsers [4][2]. A common workaround is to substitute '#' with its URL-encoded equivalent '%23' for WebDirect clients [2]. - URI Syntax: Including explicit character sets like 'charset=UTF-8' within a data URI (e.g., 'data:text/html;charset=UTF-8,...') can sometimes conflict with WebDirect's internal handling of the Web Viewer, leading to rendering failures [5]. - General URL Encoding: All URL parameters (database names, script names, script parameters) must be properly URL-encoded (e.g., space to '%20') [6][7][8]. Failing to encode special characters in these strings can lead to HTTP 500 errors or broken sessions [9]. 3. Blocked Strings: FileMaker WebDirect historically blocks specific strings in Web Viewer content. For example, the string '/fmi/webd' is restricted within Web Viewer HTML source because it conflicts with the WebDirect engine itself. If you must use such strings, developers have used workarounds like RFC 3986 encoding (e.g., '/fmi/web%64') to bypass these filters [10]. 4. Troubleshooting Checklist: - Verify that your FileMaker Server deployment is up to date, as many WebDirect rendering and encoding issues have been addressed in recent versions [11][3][6]. - Test your HTML content by stripping it down to the simplest possible version to isolate if specific characters or external resources (like CSS/JS libraries) are causing the failure [1]. - Check browser console logs for "FileMaker is undefined" errors, which often indicate that the Web Viewer failed to initialize correctly due to its content [5].

Citations:


🏁 Script executed:

printf'%s\n''--- all deploy_html references ---'
rg -n -C 4 'deploy_html|Base64Encode|data:text/html|invalid UTF-8|misdecoded|unsupported character|non-ASCII'.printf'%s\n''--- UTF-8 validity of the reviewed document ---'
python3 - <<'PY'from pathlib import Pathpath = Path("packages/webviewer/skills/webdirect-runtime/SKILL.md")data = path.read_bytes()try: text = data.decode("utf-8")except UnicodeDecodeError as exc: print(f"{path}: invalid UTF-8: {exc}")else: print(f"{path}: valid UTF-8, {len(text)} characters") for term in ("emoji", "curly quotes", "accented letters", "invalid UTF-8 sequences"): print(f"{term!r}: {term in text}")PY

Repository: proofsh/proofkit

Length of output: 12985


Limit the warning to malformed or misdecoded content.

Emoji, curly quotes, and accented letters are valid UTF-8 by themselves. State that malformed or misdecoded non-ASCII content is the failure condition, including invalid UTF-8 sequences affecting those characters.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/webviewer/skills/webdirect-runtime/SKILL.md` at line 56, Update the
character-encoding guidance in the WebDirect troubleshooting section to identify
malformed or misdecoded non-ASCII content as the failure condition, rather than
listing valid emoji, curly quotes, or accented letters as inherently
problematic. Mention invalid UTF-8 sequences affecting those characters, while
preserving the existing inspection, rebuild, redeploy, and response-check steps.


If the full WebDirect response contains the Web Viewer HTML and JavaScript bundle, don't keep treating encoding or bundle size as the default cause. Follow the browser's console and network evidence to the parse, runtime, bridge, or security failure.

Expand Down
Loading