Focus and style reads still run in the page's own world
Maintainers usually reply within 1 day
A pull request for this has already been merged.
- #341 by @eparenti — merged
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- playwright, typescript
- Domain
- accessibility, testing
Research direction
Start with focusBody, activeElementIs, activeElementWithin, and the getComputedStyle reads in src/deps/real.ts, then trace how element paths and announcement capture run in isolated worlds. Add tests where page scripts redefine each function used by these reads. Done means the reads run in an isolated world and the tests show page redefinitions cannot falsify focus or style checks.
Written by the indexing model from the issue text.
Description
What happens
Some page reads still run in the page's own JavaScript world: focusBody, activeElementIs, activeElementWithin, and the getComputedStyle reads in src/deps/real.ts. Page script can redefine document.querySelector or getComputedStyle, and then a focus check reports whatever the page wants.
Why it matters
Page text and page script are untrusted. Element paths and the announcement capture now run in isolated worlds. These reads should too, or a hostile page can pass a keyboard or focus check it fails.
Expected
Run these reads in the same kind of isolated world, and add a test for a page that redefines each function it uses.
Status
Found while moving element paths and the announcement capture into isolated worlds. The threat model lists it as not handled yet.
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 6h 25m
- Merged PRs (30d)
- 46
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from usabl-dev/usabl
-
area: engine enhancement performance
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Scan browser runs without Chromium's sandboxPossibly taken @eparenti claimed this 1 day ago. Openarea: engine security
Difficulty 4/5 3-5 days Newbie friendliness 46/100
Maintainers usually reply within 1 day
-
area: engine enhancement performance
Difficulty 4/5 1-2 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
area: engine enhancement performance
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
Similar issues
-
area:cli bug P4
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
bug from-studio
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
esengine/DeepSeek-Reasonix#14868 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
linxiv-dev/linXiv#384 · 1 comment ·
Maintainers usually reply within 1 day
-
scope:core type:security
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
mailgun/mailgun.js#544 ·