Hello,
I'd like to report a reproducible bug on challenge pages that affects Vivaldi users.
Summary
Pressing Space anywhere on a challenge page — even outside the code editor — immediately navigates to the next lesson.
Environment
- URL: https://www.rustfinity.com/practice/rust/challenges/constants
- Affected browsers: Vivaldi 8.0.4033.34 (Chromium 148.0.7778.183), reproduced on both Linux and Windows
- Not affected: Microsoft Edge, Opera
- Reproduced in Vivaldi Incognito mode → rules out extensions
- No Space keybinding configured in Vivaldi settings
Steps to reproduce
- Open https://www.rustfinity.com/practice/rust/challenges/constants in Vivaldi
- Click anywhere on the page outside the Monaco code editor
- Press Space
- The page immediately navigates to the next lesson
Expected: Space scrolls the page (standard browser behavior)
Actual: Navigation to the next lesson is triggered
Root cause analysis
I instrumented the page to intercept all keydown listener registrations and traced the full event flow. The issue is a combination of two factors:
-
Monaco Editor focus behavior on Chromium 148: After interacting with the page, Monaco leaves document.activeElement pointing at document.body rather than returning focus to a neutral element. This appears to differ from how Edge and Opera handle the same scenario.
-
Unguarded Space key handler: There is a keydown listener on document (confirmed via listener tracing) that triggers navigation on Space without first checking whether a content-editable element or editor is active. On Edge/Opera this listener never fires for Space because focus state differs, but on Vivaldi it does.
The following snippet injected into the console completely prevents the issue, confirming the cause:
document.addEventListener('keydown', (e) => {
if (e.code === 'Space' && e.target.tagName !== 'INPUT' && e.target.tagName !== 'TEXTAREA') {
e.stopPropagation();
}
}, true);
Removing the Next link from the DOM does not fix it — Space still triggers navigation (via a page reload), which confirms the handler is not simply clicking the link but is invoking router navigation directly.
Suggested fix
In the Space key handler, guard navigation by checking document.activeElement and isContentEditable:
document.addEventListener('keydown', (e) => {
if (e.code === 'Space') {
const el = document.activeElement;
const tag = el?.tagName;
if (
tag === 'INPUT' ||
tag === 'TEXTAREA' ||
el?.isContentEditable ||
el?.closest('[data-keybinding-context]') // Monaco editor container
) return;
// safe to navigate
}
});
Happy to test a fix or provide additional DevTools output. Thanks for the great resource!
Hello,
I'd like to report a reproducible bug on challenge pages that affects Vivaldi users.
Summary
Pressing Space anywhere on a challenge page — even outside the code editor — immediately navigates to the next lesson.
Environment
Steps to reproduce
Expected: Space scrolls the page (standard browser behavior)
Actual: Navigation to the next lesson is triggered
Root cause analysis
I instrumented the page to intercept all
keydownlistener registrations and traced the full event flow. The issue is a combination of two factors:Monaco Editor focus behavior on Chromium 148: After interacting with the page, Monaco leaves
document.activeElementpointing atdocument.bodyrather than returning focus to a neutral element. This appears to differ from how Edge and Opera handle the same scenario.Unguarded Space key handler: There is a
keydownlistener ondocument(confirmed via listener tracing) that triggers navigation on Space without first checking whether a content-editable element or editor is active. On Edge/Opera this listener never fires for Space because focus state differs, but on Vivaldi it does.The following snippet injected into the console completely prevents the issue, confirming the cause:
Removing the Next link from the DOM does not fix it — Space still triggers navigation (via a page reload), which confirms the handler is not simply clicking the link but is invoking router navigation directly.
Suggested fix
In the Space key handler, guard navigation by checking
document.activeElementandisContentEditable:Happy to test a fix or provide additional DevTools output. Thanks for the great resource!