Model facts that change the troubleshooting path
Apple specifies a 13.6-inch 2560×1664 display at 224 ppi.
The model has a 1080p FaceTime HD camera, a three-microphone array, a four-speaker system, MagSafe 3, and two Thunderbolt/USB 4 ports.
Test matrix
What to test and what a pass actually tells you
Run the test closest to the symptom. A passing result narrows the diagnosis; it does not certify the entire device.
Use the result as a visual/timing reference. It cannot certify panel electronics or cable signal integrity by itself.
→Use the result as a visual/timing reference. It cannot certify panel electronics or cable signal integrity by itself.
→A pass proves browser input events are arriving; app/game mappings, profiles and accessibility settings move higher on the list.
→A pass proves browser input events are arriving; app/game mappings, profiles and accessibility settings move higher on the list.
→A pass proves this browser received live camera frames; app selection, permissions or capture mode become more important if one app still fails.
→A pass proves the selected input delivered audio into this browser session; app routing or processing becomes the next branch.
→A pass proves browser playback reaches the selected output path; it does not prove every codec, surround or app-specific route.
→Use the result to narrow the next branch; browser visibility is intentionally limited to the subsystem exposed by the current API.
→Diagnostic focus
Problems worth separating on this model
Evidence handoff
If the browser cannot reach the suspected subsystem
Keep the browser result as one observation, then move to the operating system or manufacturer diagnostic that can see the protected hardware state. Do not interpret an unsupported browser API as a failed component.