Situation
I am experiencing a critical issue where large patient signatures fail to save on an OpenEMR 7.0.3 installation, while small/short signatures save successfully.
The core issue appears to be a front-end JavaScript logic failure when handling large Base64 strings, causing the browser to abort the request before it reaches the server.
OpenEMR Version
I’m using OpenEMR 7.03
Browser:
I’m using:chrome142.0.7390.108
Operating System
I’m using:ubuntu22
Search
Did you search the forum for similar questions?
Logs
Did you check the logs?
Was there anything pertinent in them?
Please paste them here (surround with three backticks (```) for readability.
You can also turn on User Debugging under Administration->Globals->Logging User Debugging Options=>All
Yes, I extensively checked all server logs at the time of the failure, but there were no records:
OpenEMR Debug Log (User Debugging): Checked, no entries for the failed POST.
PHP Error Log: Checked, no entries (no Fatal Errors or warnings).
Apache/Nginx Access Log: Confirmed a POST request to save-signature.php returned a 200 OK status, but this was a separate or subsequent request, not the one that failed in the browser.
System Logs (OOM Killer): Checked, no memory-related kills.
The browser failure occurs before a valid POST request is sent to the server.
2. The Critical Evidence (Re-emphasis):
The key is the browser’s Network Panel output for the failed attempt:
Status:failed
Time:~23ms (Immediate failure)
Name/URL: The full entry is the enormous Base64 string (data:image/png;base64,...).
This behavior confirms the JavaScript logic itself is failing locally by trying to treat the large Base64 string as a URL resource, hitting the browser’s URL length limit, and aborting the save operation.
3. Moving Forward (Based on Previous Suggestion):
Following the suggestion of another user, the fix likely involves compressing the signature data.
Could you please advise which specific JavaScript file in OpenEMR 7.0.3 handles the signaturePad.toDataURL() call for the LBF form? Knowing the file path will allow me to test switching the format (e.g., to JPEG with low quality) or reducing the canvas size to mitigate the URL length issue.