[shaohuzhang1]

fix: [Agent] The "File Upload" toggle in the basic information settings is disabled, yet the file upload button remains visible in the debugging dialog window.

[shaohuzhang1]

Overall, the diff looks syntactically valid and the refactor is reasonable. The main risk is ensuring the new canUpload computed has exactly the same semantics as the old inline condition, plus any upload-feature gating.

Potential issues

1. canUpload must include uploadEnabled

   • The template now hides the upload input/button when uploadEnabled is false.
   • However, useInputEvents now relies only on canUpload.value.
   • If canUpload does not include uploadEnabled, then paste/drag-drop handlers may still add files even though the upload UI is hidden.
   • Safest defensive option:

     canUpload: () => uploadEnabled.value && canUpload.value

     unless canUpload already incorporates uploadEnabled.

2. Guard allowedExtensions before calling .join()

   • allowedExtensions.join('、') will throw if allowedExtensions is undefined, null, or not an array.
   • Prefer a computed fallback:

     const allowedExtensionsText = computed(() =>
       allowedExtensions.value?.length
         ? allowedExtensions.value.join('、')
         : '无限制'
     )

     Then use {{ allowedExtensionsText }} in the template.

3. Ensure canUpload preserves the old conditions

   • The old condition was:

     !disabled.value && !streamLoading.value && fileList.value.length < maxFiles

   • Confirm the new canUpload computed includes all of these. If it omits any condition, the upload button and paste/drop behavior may regress.

4. v-if on the file input and fileInputRef

   • Using v-if="uploadEnabled" means fileInputRef is null while uploads are disabled.
   • That is fine if all click paths are also gated, but ensure no external code calls fileInputRef.value?.click() without checking uploadEnabled/canUpload.

5. allowedExtensions vs acceptList consistency

   • The display now uses allowedExtensions, while the file input still uses acceptList.
   • Make sure these are kept in sync or derived from the same source. Otherwise the tooltip may describe different accepted types than the actual input.

Optimization / readability suggestions

• Wrap both upload-related elements in one <template v-if="uploadEnabled"> instead of repeating v-if:

  <template v-if="uploadEnabled">
    <input ... />
    <MkTooltip ...>...</MkTooltip>
  </template>

• Consider renaming or documenting the distinction between:

  • uploadEnabled — feature-level availability
  • canUpload — current-state eligibility
    This helps avoid future confusion.

• If allowedExtensions is empty, decide whether to show “无限制” or fall back to acceptList; an empty string in the tooltip is not user-friendly.

No obvious syntax problems in the diff, but the canUpload/uploadEnabled relationship is the most important correctness point to verify.