Keep the request and result separate
A site may ask to start video when the page loads, after an account check or when a viewer presses Play. Those are application actions. The browser still applies its media policy and checks whether it can use the selected source. A request can remain pending or be rejected.
Imagine an interface that hides its Play button immediately and displays Pause before the request resolves. If the browser then refuses the start, the viewer sees controls for playback that never happened. The better interaction follows the resolved or rejected outcome and retains an ordinary way to try again.
Permission and format lead to different next steps
MDN identifies NotAllowedError for a context in which playback is disallowed and NotSupportedError for an unsupported media source. These are useful categories rather than a complete inventory of every possible application failure. Keep the actual error name if the player exposes it.
For an illustrative comparison, a direct user gesture may address a permission-related refusal while leaving an unsupported format unchanged. Conversely, choosing a supported representation does not grant an embedded page a permission it lacks. Resetting the account password is not a general repair for either category.
A useful start record
Record whether the page opened, whether an explicit Play control was used, whether an error appeared and whether the playback position advanced. A visible poster and a rotating loading symbol do not establish a decoded first frame. Keep those observations in their actual order.
For a developer report, distinguish the play promise from later media events and HTTP results. Do not repeatedly trigger the request while a permission prompt is pending. The browser may need an answer before it can complete the original request, and repeated application updates can obscure which action produced the visible result.
Questions about this guide
Does a successful page load mean playback began?
No. Media selection, access, permission and decoding are additional stages.
Should an interface assume play succeeds immediately?
No. It should handle the returned outcome and keep its controls consistent with actual playback.