Fix an invalid form method that breaks HMI web pages

What you see and what each symptom points to

• A custom file vanishes after its first open in Safari. The page loads once, a navigation control is pressed, and the file is gone from the web root until you copy it back. That points at the markup inside that file, at its navigation controls first.
• Edited standard files survive while new files vanish. The shipped pages you modified stay put and only the files you created disappear. The difference between the two sets is their markup, so start the comparison there.
• A Safari button ignores presses. Invalid form markup shows up in more than one way: some versions of Safari refuse to act on a submit button at all. Same family, same repair.
• Files vanish in other browsers too, or with nothing pressed. The navigation markup is not the trigger in this case. Check how the files were transferred and whether anything reset the panel before editing another page.

The two form methods and why anything else breaks a page

A form has one job: send data to the server that served the page. The method attribute sets how. The HTML specification defines 2 values and no more: GET, which places the form data in the requested URL, and POST, which sends it in the request body.

An unknown token such as method="Link" is invalid markup. Browsers fall back to a GET request for an unknown method value, which is why the same pages kept working in the desktop browsers. What Safari sent after meeting the invalid form, and why the panel let its own files go, was never traced. The repair needs none of that history: the form was invalid, so it has to go, and when it went, the file loss went with it in every browser the corrected pages met.

A link between two pages sends no data, so a form is the wrong mechanism for navigation even when its method is valid.

Checks that separate a markup problem from a transfer problem

1. List the web root and mark which files you created.
2. Open one suspect page in Safari and press one suspect control once.
3. Wait about 10 seconds for the panel to settle, reload the file listing and check whether the file is still there.
4. Open the same file without pressing anything, then in a second browser, and check the root again.

Replace the form with a link or a button

The failing pattern is a form wrapped around a submit input, used only to open another page:

<form method="Link" action="cf80.html">
  <input value="CF 80 Status" type="submit">
</form>

When a text link is acceptable, replace it with an anchor:

<a href="cf80.html">CF 80 Status</a>

A plain filename reaches a file in the same web root, and its capitalization has to match the deployed file: cf80.html does not open CF80.HTML on a case-sensitive server.

When the control needs a button look, use a non-submit input that moves the browser:

<input value="Home" onclick="window.location='index.html'" type="button">

Keep the control as type="button". A submit input starts a form submission, and a navigation control should never start one.

Two habits keep the rest of the page out of trouble. If a page really sends data, keep that form, set its method to get or post, and keep navigation out of it. A GET places the values in the URL, and most browsers handle a URL up to roughly 2000 characters, so keep the parameter set small. And when several forms share one HTML table, give each form its own name; forms in a shared table sometimes conflict until they are distinguished.

Example: five custom pages that vanish in Safari

Inputs:

• 5 custom HTML files added to the panel's web root, next to the panel's shipped pages: the setup in which this failure appears.
• Navigation on the new pages built as forms: method="Link", an action such as cf80.html, and a type="submit" input: the markup that triggers the loss.
• 2 valid form method values, GET and POST: the HTML specification.
• 4 browsers in service: 3 desktop browsers, which passed before the fix, plus Safari, which failed.

Rule: every form used only for navigation is one control to replace, with one anchor or one type="button" input. Forms that send data stay, with method set to get or post.

Arithmetic:

• Files lost on a Safari pass: 5 created, 5 gone, 0 modified shipped files gone. The loss follows the new files, so it follows their markup.
• Controls to replace: 1 per navigation form. A search across the 5 files for method="Link" lists every occurrence, and each occurrence becomes 1 anchor or 1 button.
• After the fix: 5 files, 0 navigation forms, 4 browsers tried, 4 passed, 0 files re-copied.

Result: the corrected set gets through a full Safari navigation pass with the web root unchanged.

Decision: a file still present in the root after being opened and navigated in Safari is fixed. A file that still disappears with the forms gone has moved the problem off the markup and onto the transfer path: preserve the before and after listings, compare them against the source copies, and stop editing pages until the two listings explain the difference.

Restore the pages without losing your work

Keep a copy of every custom file off the panel before you test or transfer anything. The corrected pages are a source change, so keep the corrected set as the master and copy it to the web root through the panel's normal project or file-transfer path. If the panel writes a USB backup, take one first; the file-type filter that catches people on restore is covered in opening an HMI panel USB backup file.

Leave the factory-default reset alone during diagnosis. On these panels a reset replaces every HTML file with the original shipped set, so it removes the custom pages and your edits in the same stroke. Recovering panel web files after a factory reset covers that path for files that are already gone.

Check the whole set before it goes back

• The web root holds every expected file before and after a full navigation pass.
• Every href and onclick target exists, with matching capitalization.
• Home and return controls work in both directions on every page.
• The Safari device that triggered the loss has opened every page and pressed every control once, then one other browser repeated the pass.

Return the pages to service when a complete pass leaves the root unchanged.

Recommendation: Build HMI web pages with navigation as anchors or type="button" controls that set window.location, and reserve forms, with method="get" or method="post", for pages that send data. If custom files have already vanished after a Safari visit, replace every form-built navigation control before you recopy anything, and verify the corrected set in Safari before the other browsers.

Questions