The logic for scrolling web pages has an extra check that we don't do when scrolling the message pane. This check only allows the page to scroll if focus is either on the page itself or on a link; scrolling is blocked if any other element has focus. This is necessary because some elements don't block the space keypress, since they only watch for a space key release. This has not usually been noticeable because the message pane normally only contains links, but RSS feeds put web pages into the message pane so we should synchronise our behaviour.
Created attachment 348962 [details] [diff] [review] Proposed patch * Prefer to scroll the focused window * If chrome has focus, scroll the content (or RSS frame as appropriate) * Otherwise, don't scroll if a non-link element has focus
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #348962 - Flags: review?(mnyromyr)
Comment on attachment 348962 [details] [diff] [review] Proposed patch >+ else if (document.commandDispatcher.focusedElement && >+ !hrefAndLinkNodeForClickEvent(event)) >+ return; Please align ! and document. My testcase: <http://www.heise.de/security/news/news-atom.xml>, whose actual HTML pages sport a search field plus button. Focusing the button and hitting space will open the Heise search page in a browser window. Only without this patch, the message pane will scroll also, which feels odd indeed.
Attachment #348962 - Flags: review?(mnyromyr) → review+
Pushed changeset 572b16f25080 to comm-central.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.0a3
You need to log in before you can comment on or make changes to this bug.