Pointer lock vs clickable choices

234. Lesson identity

Module

1.4 — Controls and input

Lesson

Pointer lock vs clickable choices

Academic type

Case Study

Order

3 in the module

Estimated time

25–40 minutes, including practice

This lesson uses the approved pointer-lock-dialogue case. Its scope is limited: it documents a collision between a flight-control context using pointer lock and dialogue choices intended for cursor-based selection. It does not document an exact event trace, implementation cause, or proven fix.

235. Learning objective

After this lesson, you can identify the two competing interaction modes in the approved case, separate the supplied observation from implementation hypotheses, and propose a one-variable test that could distinguish between explanations.

236. Why this matters

One pointing device can serve different systems at different moments. A flight-control mode may use pointer movement as gameplay input, while a dialogue mode may require cursor-based targeting of visible choices. When those requirements overlap, naming the modes and testing their transition is more precise than guessing that an event was lost or that a particular API remained active.

This discipline also gives an AI coding partner a bounded report: what the case establishes, what remains unknown, and what should be tested next.

237. Prior knowledge

You should already be able to:

• distinguish an observed result from an assumed cause;
• reproduce a control problem before proposing a patch;
• use ACT → RESPOND → CHANGE → AGAIN to compare two conditions.

The preceding lesson, Reproduce before you patch, provides that evidence discipline.

238. Terminology boundary

Use pointer lock when referring to this documented case.

Pointer Lock and the Pointer Events API’s pointer capture are distinct browser mechanisms. This lesson does not treat those terms as interchangeable and does not claim that pointer capture was involved in the case.

The phrase control ownership is only a reasoning model used in this lesson. It asks which system is intended to control the pointing device in a given mode. It is not the name of a literal browser API state.

239. Source-bounded case record

The following is the complete evidence supplied for this lesson:

The observed result above is a supplied case fact. No additional artifact or event trace is provided from which to infer a more specific symptom. Therefore, this lesson does not claim that a click was discarded, that a particular event failed to reach the interface, that pointer lock remained active at a specific frame, or that a known patch solved the collision.

240. Core concept

Two modes can require incompatible uses of the same pointing device.

In this case, the competing modes are:

• Flight-control mode: uses pointer lock as part of gameplay control.
• Dialogue-selection mode: requires cursor-based targeting of visible dialogue choices.

The conflict should be described as an incompatibility between interaction modes or as cursor-based targeting being unavailable when it is needed. That bounded description does not assume that UI events were necessarily lost.

The diagnostic question is:

Which system is intended to control the pointing device at this moment, and which part of that claim is supported by the supplied case record?

241. Evidence model

Classify every statement as Observation, Hypothesis, or Test evidence.

An observation states what the approved record supplies. A hypothesis proposes an explanation that still needs evidence. Test evidence is produced only after a controlled comparison is performed and recorded.

242. Diagnostic loop

Apply the lesson loop without assuming a cause:

1. ACT: repeat the same attempt to select a dialogue choice.
2. RESPOND: record the visible result without inferring an event path or API state.
3. CHANGE: alter one relevant mode condition only.
4. AGAIN: repeat the same selection attempt and compare the visible result.

The changed condition must be explicit. If several input rules, UI elements, and bindings change at once, the comparison cannot identify which change mattered.

243. Worked classification

Consider these three statements:

1. “The case places pointer-locked flight control and cursor-selectable dialogue choices at the same interaction boundary.”
2. “Pointer lock remained active when the player attempted the selection.”
3. “Repeat the selection attempt after changing only whether the dialogue is treated as the active pointer-interaction mode.”

Classify them as follows:

• Statement 1 is an observation supplied by the case.
• Statement 2 is a hypothesis because the case provides no frame-level state record.
• Statement 3 is a test plan because it changes one condition and repeats the same action.

If the repeated attempt produces a recorded difference, that comparison becomes test evidence. It would support or weaken the hypothesis, but it would not automatically prove a complete implementation cause or final fix.

244. Guided practice

Complete the table using only the source-bounded case record.

Now choose the most discriminating first test:

• A: Change several bindings, replace the dialogue UI, and alter the mode transition together.
• B: Keep the player action and dialogue unchanged, alter only which interaction mode is active for the pointing device, and repeat the selection attempt.
• C: Repeat the original attempt without changing or recording any condition.

Choose B. It examines the boundary identified by the case while holding the action and interface constant. It remains a test proposal, not a verified patch.

Write a two-sentence justification:

1. one observation copied or closely paraphrased from the case record;
2. one explicitly labeled hypothesis that the test could support or weaken.

245. Common mistakes

Treating pointer lock and pointer capture as synonyms

They are distinct mechanisms. The documented case concerns pointer lock. Do not rename it pointer capture.

Treating control ownership as a literal API state

Control ownership is a diagnostic model for discussing which system should control the pointing device. Verify actual API state separately if evidence becomes available.

Inventing a missing symptom

The supplied record establishes a collision but does not specify that an event was lost or that a particular system received it. Record only the visible result available during a reproduction.

Calling a plausible change a proven fix

A one-variable comparison can provide evidence for or against a hypothesis. It does not establish a complete fix without further validation.

246. Validation

Your work is sufficient when it contains:

1. the flight-control mode using pointer lock;
2. the dialogue-selection mode requiring cursor-based targeting;
3. the supplied setup, player action, and observed collision;
4. a clear distinction between pointer lock and pointer capture;
5. one implementation explanation labeled as a hypothesis;
6. one test that changes only a single mode condition;
7. the visible result to compare before and after that change.

Do not claim that pointer lock remained active at a particular frame, that an interface event was lost, or that a specific patch resolved the case unless separate evidence establishes it.

247. Key takeaways

• The documented case concerns pointer lock, not pointer capture.
• Control ownership is a reasoning model, not a literal API state.
• The supplied case fact establishes a collision between two incompatible pointer-interaction modes.
• The exact implementation condition and fix remain unestablished.
• A useful test changes one mode condition and repeats the same player action.

248. Next lesson

Continue to 1.5 — Camera.

Carry forward the evidence table and choose one observed control moment from it. In the next lesson, use that moment to write a bounded intent sentence stating what the player must see, without adding an unverified implementation explanation.

249. CONTRABAND

• Classification: Pointer-lock dialogue
• Use in this lesson: Approved case establishing a collision between flight control using pointer lock and cursor-selectable dialogue choices.
• Boundary: The case does not establish an exact symptom trace, implementation cause, date, metric, project history, or proven fix.

250. Knowledge check