Recording docs: video is on by default, and Java gets examples - #410
Open
hugs wants to merge 3 commits into
Open
Recording docs: video is on by default, and Java gets examples#410hugs wants to merge 3 commits into
hugs wants to merge 3 commits into
Conversation
Video is on by default wherever the engine supports it; video: true is the strict mode that fails when it cannot be delivered. Every sample led with video: true, so it read as the switch that turns video on -- and on the default engine that sample throws. The tutorial now shows recording.start() with no options and explains the three settings as a list; 'video: true requires it' had no clear antecedent. The how-to opens with 'no option needed'. Its client examples keep video: true, which is right for a script whose purpose is the video, and now say why inline. The Firefox capability table labels the feature recording.start() rather than the strict form.
The options were a parenthetical -- 'Dimensions default to the viewport
(video: { width, height, frameRate } to override)' -- which named the fields
without showing a call or saying what they do.
Running them turned up two behaviours the parenthetical hid:
- Passing an object implies video is required, the same as video: true.
- The size is a request, not a setting. The engine keeps the viewport's
aspect ratio and derives the other side. Verified on Firefox 154 beta:
{ height: 480 } encodes 854x480, and { width: 640, height: 480 } encodes
640x360 on the same viewport.
Both are now stated, with the stop result shown as the way to see what was
actually encoded. Python's snake_case spelling gets its own snippet.
remote-browser.md had JavaScript and Python for both connecting and authenticating, and no Java at all. recording.md documented video sizing in JavaScript and Python only. Java's shape differs enough to be worth showing rather than leaving readers to translate: connecting goes through StartOptions().connectURL() rather than a URL argument to start(), headers through connectHeaders(Map), and video options are flat setters. videoSize takes both dimensions, so the height-only form the JavaScript and Python examples use has no Java equivalent -- the example picks a pair on the viewport aspect and says why. Every snippet was compiled against the 26.8.21 JAR before being written down.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three things in the recording and remote-browser tutorials, all found by running the code.
Video looked opt-in. Every sample led with
{ video: true }, so it read as the switch that turns video on. Video is already on wherever the engine supports it;trueis the strict mode that fails when it can't be delivered — and on the default engine that sample throws. Samples now showrecording.start()with no options. The two client examples inrecord-video.mdkeepvideo: true, which is right for a script whose purpose is the video, and say so inline.The dimension options were a parenthetical. Running them turned up two behaviours it hid:
video: true(recording.go:99).{ height: 480 }encodes 854×480, and{ width: 640, height: 480 }on the same viewport encodes 640×360 — the engine keeps the viewport aspect and derives the other side.Both are now stated, with
result.videosshown as the way to see what was actually encoded.Java examples.
remote-browser.mdhad none;recording.mddocumented video sizing in JavaScript and Python only. Java's shape differs enough to be worth showing:StartOptions().connectURL()rather than a URL argument,connectHeaders(Map), and flat video setters. Every snippet compiles against the 26.8.21 JAR.videoSizerequires both dimensions, so the height-only form has no Java equivalent — the example picks a pair on the viewport aspect and says why. Filed as #409.Also fixes "
video: truerequires it", whose it had no antecedent.