Launchpad has imported 21 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=669026.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-07-03T01:54:31+00:00 Jruderman wrote: Split from bug 549262. 1. Load the testcase, https://bugzilla.mozilla.org/attachment.cgi?id=459420 2. Press the down arrow key several times. Result: scrolls to the top of the pink div and stops. Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/58 ------------------------------------------------------------------------ On 2011-07-03T11:18:53+00:00 Xtc4uall wrote: Happens on Windows too => OS = All. Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/59 ------------------------------------------------------------------------ On 2011-07-15T19:24:01+00:00 Ehsan-mozilla wrote: Possibly even a dupe of bug 549262... Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/60 ------------------------------------------------------------------------ On 2011-07-15T21:01:38+00:00 Ehsan-mozilla wrote: (In reply to comment #2) > Possibly even a dupe of bug 549262... Oh, forget this comment, I was totally confused. Boris, is it possible to specify a "fallback" action for the arrow keys? Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/61 ------------------------------------------------------------------------ On 2011-07-15T21:02:00+00:00 Ehsan-mozilla wrote: I'm on fire today! Boris, see comment 3. :-) Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/62 ------------------------------------------------------------------------ On 2011-07-15T23:27:36+00:00 Bzbarsky wrote: I don't know offhand.... Neil might. Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/63 ------------------------------------------------------------------------ On 2011-07-15T23:30:17+00:00 Neil-httl wrote: (In reply to comment #5) > I don't know offhand.... Neil might. I don't understand the question... Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/64 ------------------------------------------------------------------------ On 2011-07-18T18:25:13+00:00 Ehsan-mozilla wrote: So, here is the problem. In platformHTMLBindings.xml, we define a VK_DOWN handler for caret navigation command so that you can go to the next line in editor by pressing down for example. If there is no editable element focused, we need the default behavior of scrolling the page down to take place, so we need some kind of a fallback event handler being bound to VK_DOWN. Is there any way to do that? Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/65 ------------------------------------------------------------------------ On 2011-07-18T21:39:03+00:00 Neil-httl wrote: (In reply to comment #7) > So, here is the problem. In platformHTMLBindings.xml, we define a VK_DOWN > handler for caret navigation command so that you can go to the next line in > editor by pressing down for example. If there is no editable element > focused, we need the default behavior of scrolling the page down to take > place, so we need some kind of a fallback event handler being bound to > VK_DOWN. Is there any way to do that? There is a way to do that, but you have to bind your handlers and attach your controllers to the focused element rather than the window root as you currently do. The second approach is to fix the editor's command controller to work with editable regions. The third approach is to stop editor from handling the up and down arrow keys. If you look at the global window controller you'll see that if it thinks there's a caret then it will try to do caret movement instead of scrolling. I think the test detects design mode but not contentEditable regions, so it still tries to do scrolling in that case. Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/66 ------------------------------------------------------------------------ On 2011-07-27T18:40:41+00:00 Ehsan-mozilla wrote: *** Bug 505732 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/73 ------------------------------------------------------------------------ On 2011-07-27T19:58:13+00:00 Neil-httl wrote: (In reply to comment #8) > The third approach is to stop editor from handling the up and down arrow > keys. If you look at the global window controller you'll see that if it > thinks there's a caret then it will try to do caret movement instead of > scrolling. I think the test detects design mode but not contentEditable > regions, so it still tries to do scrolling in that case. It does detect contentEditable regions. But some focus code to make link focusing work in caret browsing mode blurs the region :-( See nsSelectMoveScrollCommand::DoCommandBrowseWithCaretOn() Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/75 ------------------------------------------------------------------------ On 2011-07-27T21:43:01+00:00 Ehsan-mozilla wrote: Created attachment 548924 Patch (v1) Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/76 ------------------------------------------------------------------------ On 2011-07-27T21:56:59+00:00 Ehsan-mozilla wrote: *** Bug 481626 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/77 ------------------------------------------------------------------------ On 2011-07-27T22:55:08+00:00 Neil-httl wrote: Created attachment 548949 Proof of concept The editor-base.inc change remaps VK_UP to cmd_scrollLineUp because that was easier to prototype, but ideally it would be renamed back to cmd_linePrevious throughout the codebase. The editor command handler is ruled out of the equation, and that code should be removed. The nsGlobalWindowCommands already knows how to move a caret, so that doesn't change, but the focus manager has to be told not to blur a contenteditable region. Note that even with caret browsing on, this code doesn't move focus in to a contenteditable region either. I don't know whether this is reasonable. Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/78 ------------------------------------------------------------------------ On 2011-07-27T23:02:04+00:00 Ehsan-mozilla wrote: I don't understand why the focus manager change there is OK... Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/79 ------------------------------------------------------------------------ On 2011-07-28T00:31:53+00:00 Masayuki wrote: Why don't you make nsEditor::IsActiveInDOMWindow() an insterface method of nsIEditor? And, PageUp, PageDown, Home, End keys need to be handled too. (I'm not sure about Shift+Arrow or them) Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/80 ------------------------------------------------------------------------ On 2011-07-28T17:53:31+00:00 Ehsan-mozilla wrote: *** Bug 674860 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/83 ------------------------------------------------------------------------ On 2011-07-28T18:41:58+00:00 Neil-httl wrote: Comment on attachment 548949 Proof of concept Well, I might as well ask for review on the nsFocusManager change, just in case... the point here is that we don't normally get here because the editor command handlers are active in contenteditable mode, but I want to be able to remove the editor motion command handlers because the global ones work anyway, except for the issue that they blur contenteditable regions, which is unwanted. Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/84 ------------------------------------------------------------------------ On 2011-08-01T01:20:27+00:00 Roc-ocallahan wrote: Ehsan, does Neil's approach sound better to you? It does to me. Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/85 ------------------------------------------------------------------------ On 2011-08-01T22:06:02+00:00 Asa wrote: Is this a regression in 6? How widespread is this likely to be? We're just a few days from the final Beta of 6. Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/86 ------------------------------------------------------------------------ On 2011-08-01T22:08:21+00:00 Lpsolit-gmail wrote: (In reply to comment #19) > Is this a regression in 6? How widespread is this likely to be? We're just a > few days from the final Beta of 6. This is not a regression in 6, from what Ehsan said on IRC, but e.g. planet.m.o is unusable using keys for several days now, due to this bug. Reply at: https://bugs.launchpad.net/firefox/+bug/107247/comments/87 ** Changed in: firefox Status: Unknown => In Progress ** Changed in: firefox Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/107247 Title: Launchpad bug pages trigger caret browsing in Firefox and other Gecko browsers To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/107247/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
