fix(html): editing scope paragraph holds the range, not the style - #909
Merged
Merged
Conversation
andiwand
force-pushed
the
fix/format-is-held-by-the-range
branch
from
September 20, 2026 09:06
f8292b2 to
3410833
Compare
`odr.editing.format` refused every call under scope `paragraph`, so a host that narrows the scope could offer no formatting at all - not bold on one word, not a highlight inside a sentence. Marking runs inside one paragraph opens no paragraph and joins none, so the scope was refusing something it is not about. It now refuses on the test every other edit uses, `outOfScope(at)`: a range inside one paragraph is taken, one over two is refused. Which styles are offered stays the host's, because the host draws the buttons. The one path it cannot draw is the keyboard, so the `formatBold` chords stay behind the gate, and `keyboard_shortcuts` remains the switch that takes every chord away. Checked with `test/browser/text` - 196 checks, none failing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FJJdfqpnVCKBNHXjAVxSou
andiwand
force-pushed
the
fix/format-is-held-by-the-range
branch
from
September 20, 2026 09:35
3410833 to
d61f21a
Compare
The reason a chord keeps the gate belongs at the chord, and `format` only needs to say that the scope holds the range. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0149gFxhkvKTBQidz6brU8Vt
andiwand
added a commit
to opendocument-app/OpenDocument.droid
that referenced
this pull request
Sep 20, 2026
…ol (#668) * Rebuild the editing UI around one tool per tap, and sell it by the tool The strip under the edit bar was up to eleven targets wide and scrolled on a phone: every marking tool carried a second button for its colour, and undo and redo sat at the end where a pdf pushed them off the screen. The strip is now formatting alone. Undo, redo and save are `menu/edit.xml`, so they stand in the bar and do not scroll away, and `EditActionModeCallback` dims them on what the page reports. A sheet or a plain text file shows no strip at all. Every tool is one 48dp square: a tap does the tool's one job and a long press opens the colours it applies, so the chevrons are gone. The colour bar under an icon is what the next tap uses, and it sits at the foot of a deep slot - close under the ink, a squiggle that dips and a strikethrough that stops high read as bars at different heights. The fourteen font sizes are a row under the strip rather than a menu down the screen, scrolled to the size the text is in. A pdf's tools no longer arm themselves. `odr.annotation.press` marks a standing selection and arms only what it could not mark, so `PageView.pressMarkTool` puts every tool but the pen back down. With nothing selected the answer is the `action_annotate_banner` snackbar. The page's `markOnSelection` is therefore off: it marked as the selection was made, which is the opposite order. The bridge states the sheet's gesture too, because an android WebView reports a fine pointer on an emulator. The gate moved from the mode to the tool. Every edition opens every kind the core calls editable, and a locked strip dims what only offers pro and leaves the highlighter working - `highlight` being the formatting style and the pdf's marking tool alike. A mode nobody can do anything in is not worth opening. The two offers say what is still pro; their translations are dropped rather than left stating the old, now false, thing. No string is new: every label reuses one the app already has in nineteen languages, and `action_edit_banner` is gone from all of them. The free highlighter in a text document wants a core carrying opendocument-app/OpenDocument.core#909, which is unreleased: against 7.1.0 the page refuses it and the offer of pro comes up, as it does today. Checked on a Pixel 6 Pro emulator in both themes and both editions: 97 instrumented tests on pro, 97 on lite, the unit tests, lint, and all three flavors build. * Draw the highlighter as one, rather than as a third pencil `ic_marker` was Material's `edit` icon, so the highlight tool, the Draw tool and the Edit button were all pencils: `ic_edit` on the button that edits a document, `ic_marker` on the one that marks up a pdf and on the highlighter beside `ic_draw` in the strip. At 22dp they were not worth telling apart. It is now a highlighter: the wedge nib that says the ink goes on in a band, the barrel, and the cap at the back. The colour it lays down is still the bar under it. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
odr.editing.formatrefused every call under scopeparagraph, so a host that narrows the scope could not offer any formatting at all - not bold on one word, not a highlight inside a sentence. Marking runs inside one paragraph opens no paragraph and joins none, so the scope was refusing something it is not about.It now refuses on the same test every other edit uses,
outOfScope(at): a range that starts and ends in one paragraph is taken, and one reaching over two is refused.Where the gate stays
Which styles are offered is the host's to decide, because the host draws the buttons. The one path it cannot draw is the keyboard, so the
formatBoldchords keep the scope gate: a host that offers less has no way to take a key away.HtmlConfig::keyboard_shortcutsstays the blunt switch, and it is too blunt for this on its own - it also carries undo and redo, which every edition offers.So the split is: what the host draws, the host gates; what it cannot draw, the scope gates.
This is what a tiered app needs: OpenDocument Reader's free edition narrows the scope to
paragraphand wants to offer one formatting tool rather than none.Checked
test/browser/text: 196 checks, none failing. The scope group now checks that the chord is still refused, that the host's ownformatmarks a run inside one paragraph, and that a format over two paragraphs is refused asoutOfScope.