Closed Bug 421718 Opened 17 years ago Closed 17 years ago

going back to page with textarea makes page look editable (has caret, arrow keys operate caret)

Categories

(Core :: DOM: Editor, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 421169

People

(Reporter: dbaron, Unassigned)

References

Details

(Keywords: regression)

Going back to a page where a textarea was focused puts the page in a semi-editable mode (caret browsing?) where the arrow keys move a caret (which, when it moves offscreen, eventually scrolls the page) rather than scrolling the page. Steps to reproduce: 1. load this bug report (and don't make any changes) 2. click in the "Additional comments" textarea 3. Hit the "Commit" button 4. hit the browser's back button 5. click on the text a little above the textarea 6. hit the up and down arrow keys Actual results: 5. caret appears 6. pressing up and down arrows moves the caret (and the page scrolls when the caret hits the edge of the screen) Expected results: 5. no caret 6. up and down arrow keys scroll the page This regressed between Linux nightlies 2008-02-26-04-trunk and 2008-02-27-04-trunk.
Flags: blocking1.9?
This is a dupe of bug 421169. What's happening here, is that when you click on the "commit" button, it gets focus. When you navigate back to the page, nsEventStateManager::ResetBrowseWithCaret() is called, and this turns on caret visibility if the focused node is editable, and <input>s have their editable flag set (even for type=button), so the caret is made visible. I'm not sure why the caret doesn't show up immediately beside the button, maybe because its last position was in the textarea or something, but the patch for bug 421169 fixes this, so duping.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.