gates 12/32/38: two text-extraction false positives and one that scores a comment

[rubenvdlinde]

Three text-extraction defects, measured on ConductionNL/softwarecatalog against hydra-gates@main (756fe89), run over the full tree. Two produce false positives on correct code; the third makes a gate score a comment.

---

1. gate-12 (nc-input-labels): [^>]* stops at the arrow in an arrow function

run-hydra-gates.sh:

grep -oE '<NcSelect[^>]*>' 2>/dev/null \
    | while IFS= read -r tag; do
        if ! echo "${tag}" | grep -qE "(input-label|inputLabel|aria-label-combobox|ariaLabelCombobox)"; then

[^>]* stops at the first >. In an NcSelect with a reducer — which is the idiomatic way to keep the stored value a plain string rather than the {label,value} option object — that first > is the arrow:

<NcSelect
  v-model="emailSettings.transportType"
  :reduce="option => option.value"      <-- extraction ends HERE
  :options="[…]"
  input-label="Transport Type"          <-- never seen
  :disabled="!emailSettings.enabled" />

The extracted "tag" ends before input-label can appear, so a correctly-labelled select is reported as unlabelled. The finding text in the log shows the truncation directly — it literally ends at :reduce="option =>.

Measured: both gate-12 findings on softwarecatalog are this. Both selects carry input-label. The gate has been red on this repo for a WCAG rule the repo already satisfies.

This is the same shape as the gate-9 admin rule's [^)]* in #198, and it fails the same two ways at once: any prop value containing > truncates the tag (false positive), and the truncated remainder is discarded rather than re-scanned.

Suggested fix: extract to the tag's real close — track quoting, or at minimum <NcSelect(\s+[^>]*?)?/?> with quoted-value awareness. Whatever the mechanism, the unit tests should include a tag with an arrow function before the label prop, since that is the ordering the false positive needs.

---

2. gate-32 (semantic-controls): matches markup inside Vue comments

The fix for gate-32 on softwarecatalog added an explanatory comment above each repaired element:

<!-- role/tabindex/keydown rather than a bare <div @click>: picking the
     merge target is the consequential choice in this dialog … -->
<div v-for="obj in availableObjects"
     role="option"
     tabindex="0"
     @click="selectTargetObject(obj)"
     @keydown.enter.prevent="selectTargetObject(obj)">

The gate still reported all three files — and the reported tag was <div @click> with no attributes, i.e. the comment, not the element. Rewording the comments to prose ("rather than a click-only div") cleared the gate with no change to the markup.

This was confirmed, not assumed: the same tree was measured before and after the comment rewording, with the element markup byte-identical across both runs. gate-32 went FAIL(3) → PASS.

Consequence in both directions:

• a correct element whose comment describes what it replaced is reported (false positive), and
• a genuinely bad element can be "explained away" by a comment — which is worse, because the natural next step for someone chasing this gate is to write a comment.

Same class as #184: a checker that greps a string literal misses every constant and matches every comment.

Suggested fix: strip <!-- … --> from the template before scanning, as the other Vue-template gates do.

---

3. gate-38 (skip-link): a Nextcloud admin-settings section is not a root component

gate-38 reports templates/settings/admin.php on softwarecatalog:

Util::addScript($appId, $appId . '-settings');
Util::addStyle($appId, 'main');
?>
<div id="softwarecatalog-settings"></div>

That template is registered via lib/Settings/SoftwareCatalogAdmin.php (an OCP\Settings\ISettings) and is rendered inside core's settings frame, which already supplies the skip link and the <NcContent> shell. It is not a root component and never controls the page's landmark structure. Adding a second skip target inside the settings shell would be an accessibility regression, so the gate's advice is actively wrong here.

Suggested fix: exclude templates that are only reachable through an ISettings::getForm() implementation — i.e. any templates/settings/*.php whose name appears in a new TemplateResponse(..., 'settings/…') returned from a class implementing OCP\Settings\ISettings. A cheaper approximation: skip templates/settings/.

---

Why these were reported rather than worked around

None was silenced in the app. No waiver, no exclude tag, no baseline entry. softwarecatalog's PR #458 leaves gate-12 and gate-38 red and says why, with the call-path evidence above.

[rubenvdlinde]

Parts 1 and 2 fixed and merged to main in #269 (cdfbd7a). Part 3 needed no change — #247 already fixed it. Details below.

---

1. gate-12 — [^>]* stops at the arrow ✅ fixed

Extraction is quote-aware now: a > inside a quoted attribute value does not end the element. As you asked, the unit suite includes a tag with an arrow function before the label prop, since that is the ordering the false positive needs.

Measured post-merge on openconnector, attribution-isolated (main@32fa23e → main@cdfbd7a), from the runner's stdout:

A (before): [gate-12] nc-input-labels: FAIL — 13 NcSelect without inputLabel/ariaLabelCombobox
B (after):  [gate-12] nc-input-labels: FAIL — 10 NcSelect without inputLabel/ariaLabelCombobox

The 3 removed are exactly the truncations, each verified by hand — EditRule.vue, and two in EditSynchronization.vue, all carrying input-label= written after :selectable="(option) => …". The remaining 10 are real. This is the same shape as gate-9's [^)]* in #198, as you noted.

The credit for the helper belongs to #219, which is superseded by this PR: its check_nc_select_labels.py and all 17 of its tests are carried here, rebased onto current main (it no longer merged cleanly) and converged onto the shared scope so a <NcSelect> named in a <script> docblock is not scanned either.

2. gate-32 — a comment is scored as an element ✅ fixed

Fixed in both directions on source_scope.markup_mask, shared with gates 12 and 31 as you suggested. The false positive goes, and — more importantly — a genuinely bad element can no longer be explained away by writing a comment about it, which was the direction that worried you.

⚠️ The count on softwarecatalog went UP, and that is the fix working. 2 → 3, and the third is a true positive the old gate structurally could not report:

<div class="summary-item errors"
     :class="{ clickable: importResult.statistics.summary.total_errors > 0 }"
     @click="showErrorDetails">

ArchiMateImportExport.vue:155. The > inside the :class value truncated the tag, so @click was never seen. Same defect as gate-12's, opposite sign.

3. gate-38 on templates/settings/admin.php — already fixed by #247

Your call-path evidence was right and the fix landed independently: #247 stopped gate-38 asking every app template for a skip link and now asks only whether the template owns the document (scripts/lib/php_template_scope.py, classifying emitted markup with PHP regions and HTML comments removed). Measured: all 30 app templates in the fleet are fragments, softwarecatalog's included — it emits <div id="softwarecatalog-settings"></div> and no <html>/<body>.

Confirmed here on softwarecatalog with a full-tree run in both arms:

A: [gate-38] skip-link: PASS
B: [gate-38] skip-link: PASS

The remedy you called an accessibility regression — a second skip target inside core's settings shell — is exactly the argument #247 landed on (#214 / #216 / #227). Your suggested approximation ("skip templates/settings/") was not needed; the document test is stricter and does not need a path convention.

⚠️ #266 reported gate-41 (html-lang) carrying gate-38's pre-#247 defect verbatim — a PHP comment mentioning <html> made a mount point read as a page root. That is fixed in this same PR, converged onto php_template_scope rather than adding a third scope definition.