Open
Bug 1425546
Opened 8 years ago
Updated 3 years ago
Ctrl+W shouldn't close window/tab without warning when in textarea
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
UNCONFIRMED
People
(Reporter: solar, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346
Steps to reproduce:
Start typing into a textarea on a web page (e.g., a wiki edit or a forum comment), press Ctrl+W attempting to delete last word (a familiar keystroke to many of us).
Actual results:
The tab or window closes. Luckily, on Firefox 57 restoring the tab/window appears to restore the textarea contents as well, so it's not as bad as IIRC it used to be.
Expected results:
With default key bindings, I'd like either nothing to happen on Ctrl+W or a warning about possibly unsaved edits to appear when there have been user edits since the page load in any textarea or input, or if that's too difficult to check for then if the text cursor is currently in a textarea or an input.
A related bug is #72352. It hasn't received a comment in 8 years and it doesn't appear to be the same as this one, although some of the bugs closed as its duplicates maybe were actually closer to this one. None of those other bugs appear to have suggested as a fix the behavior I described above.
A partial workaround is to enable Emacs key bindings e.g. per instructions at http://shallowsky.com/blog/linux/gtk3-emacs-key-theme.html but few people will - most of those affected by this issue will probably continue to curse and suffer. There's also the issue of occasionally using Firefox on someone else's computer, without custom configuration.
Updated•8 years ago
|
Component: Editor → Keyboard: Navigation
Comment 1•8 years ago
|
||
(In reply to solar from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101
> Firefox/57.0
> Build ID: 20171112125346
>
> Steps to reproduce:
>
> Start typing into a textarea on a web page (e.g., a wiki edit or a forum
> comment), press Ctrl+W attempting to delete last word (a familiar keystroke
> to many of us).
>
>
> Actual results:
>
> The tab or window closes. Luckily, on Firefox 57 restoring the tab/window
> appears to restore the textarea contents as well, so it's not as bad as IIRC
> it used to be.
>
>
> Expected results:
>
> With default key bindings, I'd like either nothing to happen on Ctrl+W or a
> warning about possibly unsaved edits to appear when there have been user
> edits since the page load in any textarea or input,
Jessica, do you think the suggested behavior is feasible?
> or if that's too
> difficult to check for then if the text cursor is currently in a textarea or
> an input.
>
> A related bug is #72352. It hasn't received a comment in 8 years and it
> doesn't appear to be the same as this one, although some of the bugs closed
> as its duplicates maybe were actually closer to this one. None of those
> other bugs appear to have suggested as a fix the behavior I described above.
>
> A partial workaround is to enable Emacs key bindings e.g. per instructions
> at http://shallowsky.com/blog/linux/gtk3-emacs-key-theme.html but few people
> will - most of those affected by this issue will probably continue to curse
> and suffer. There's also the issue of occasionally using Firefox on someone
> else's computer, without custom configuration.
Flags: needinfo?(jjong)
Priority: -- → P3
Comment 2•8 years ago
|
||
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #1)
> (In reply to solar from comment #0)
> >
> > With default key bindings, I'd like either nothing to happen on Ctrl+W or a
> > warning about possibly unsaved edits to appear when there have been user
> > edits since the page load in any textarea or input,
>
>
> Jessica, do you think the suggested behavior is feasible?
>
This sounds to me something that should be done with `beforeunload`, since textarea/input are in web content.
Flags: needinfo?(jjong)
Assignee | ||
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•