experiments in a post-browser web
fix(page-host): ESC must not navigate back
Removes the `webview.goBack()` branch from the page-host escape
handler. ESC silently rewriting webview history is wrong:
- Browser convention is that ESC dismisses inputs / stops loading;
"back" is cmd+[ or the navbar back button.
- It's a data-loss vector — typing into a form, hitting ESC, losing
the page.
- It contradicts peek's ESC discipline (ESC unhandled at workspace
root opens the Windows switcher, not navigates).
After this change, ESC at workspace root falls through to the
backend escPolicy (which returns the appropriate decision per
window role — e.g. open Windows switcher for content windows).
The find-bar / notes-textarea / navbar / pagestream branches above
still consume ESC when relevant.
+6
-5
+6
-5
app/page/page.js
+6
-5
app/page/page.js
···
2142
2142
DEBUG && console.log('[page] ESC: pagestream browsing, closing window');
2143
2143
return { handled: false }; // let backend close
2144
2144
}
2145
-
if (webview.canGoBack()) {
2146
-
DEBUG && console.log('[page] ESC: webview going back');
2147
-
webview.goBack();
2148
-
return { handled: true };
2149
-
}
2145
+
// ESC must NOT navigate back. Browser convention is that ESC dismisses
2146
+
// inputs / stops loading; "back" is cmd+[ or the navbar back button.
2147
+
// Silently rewriting history on ESC is a data-loss vector (e.g. user
2148
+
// typing into a form, hits ESC, loses the page). For internal page-host
2149
+
// history (typed an address, navigated, hit ESC), prefer dropping the
2150
+
// typed-address entry from history rather than triggering navigation.
2150
2151
// In space mode, ESC at root should close this page and return to the group view.
2151
2152
// The backend escPolicy returns 'nothing' for content windows in active sessions,
2152
2153
// so we must close the window directly from the renderer.