Audit follow-up: Edit content pristine timer can race slow async fields
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 970
- Forks
- 486
- Avg merge
- 3d 33m
- Merged PRs (30d)
- 170
Description
Parent epic: #36004
Finding
dot-edit-content-form.component.ts reportedly uses #scheduleMarkPristineAfterInit with a blind 500ms timer. Slow async fields can load after the timer and mark the form dirty.
Report reference: dotcms-ui/src/app/portlets/dot-edit-content/dot-edit-content-form.component.ts:383-389
Potential impact
Users may get false unsaved-changes prompts on slow environments even when they only viewed content.
Suggested validation
Throttle async field loading or network responses and observe form pristine/dirty state after initial load.
Possible fix
Replace the fixed delay with explicit readiness coordination from async fields / form initialization state.
Caveat
This was AI-found by Claude from .scratch/audit/REPORT.md. Please perform secondary validation of correctness, severity, and value before actioning.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Inspect dotcms-ui/src/app/portlets/dot-edit-content/dot-edit-content-form.component.ts around lines 383-389, starting with #scheduleMarkPristineAfterInit and the async field initialization flow. Reproduce the issue by throttling async field loading or network responses, then verify that the form remains pristine after initial loading without relying on a fixed timer.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- angular, typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100