To reproduce: 1. Press F7 to switch to Caret Browsing. 2. Press Ctrl+LeftArrow or Ctrl+RightArrow to quickly move the caret to a link Result: The link is not activated when the caret is located on a link. It should. Prog.

Ctrl+arrow move the caret to prev/next word. Tab/Shift+Tab will move the caret to next focus/link.

Ginn, the links should also get focused when the caret moves over them.

MoveFocusToCaret should be called after DoSelectCommand

Comment on attachment 162558 [details] [diff] [review] patch I don't really know this code, so I'm not sure when I'll be able to review. It won't be in the next week, no matter what.

I'm just moving |esm->MoveFocusToCaret(PR_TRUE, &dummy);| out of nsSelectMoveScrollCommand::DoSelectCommand So that we'll also call MoveFocusToCaret() after nsSelectCommand::DoSelectCommand The Ctrl+Arrow movement is in nsSelectCommand::DoSelectCommand.

Comment on attachment 162558 [details] [diff] [review] patch sr=bzbarsky. I'm very sorry this took so long; I needed to find time to read and understand the surrounding code... Please let me know if you need me to check this in, ok? And thank you for the patch!

Thanks, bz. Although this patch works, I find a better one now. We don't want shift+(ctrl)+arrow (i.e. selection command) focus links. I'll work on it in next week after my vacation.

To separate caret movement commands and selection commands, and now we can define home/end as line movement with caret browsing on.

Ginn, why would we want to MoveFocusToCaret after every command? + if (NS_SUCCEEDED(rv) && esm && esm->GetBrowseWithCaret()) { + PRBool dummy; + esm->MoveFocusToCaret(PR_TRUE, &dummy); + } Does't that mean that just down arrowing would possibly move the focus even though the user is not in caret mode? It should just scroll the page at that point. Maybe it's okay. Right now I can't think of times when the focus and caret will not be in sync. What do you think?

Comment on attachment 167097 [details] [diff] [review] patch v2 Ginn, I'll plus it if you can tell me why the MoveFocusToCaret() call was moved, and why we want WordMove even if browser with caret is off.

WordMove is called from nsSelectCommand::DoSelectCommand, which is not different for caret browsing on or off. So I moved it to nsSelectMoveScrollCommand::DoSelectCommand. I think move it to DoCommandBrowseWithCaretOn will be OK. If we move calling WordMove to DoCommandBrowseWithCaretOn, We can call MoveFocusToCaret() from DoCommandBrowseWithCaretOn. It looks that will be better.

Checking in nsGlobalWindowCommands.cpp; /cvsroot/mozilla/dom/src/base/nsGlobalWindowCommands.cpp,v <-- nsGlobalWindowCommands.cpp new revision: 1.14; previous revision: 1.13 done

(In reply to comment #8) >and now we can define home/end as line movement with caret browsing on. I couldn't get this to work, even after tweaking platformHTMLBindings.xml

(In reply to comment #14) > (In reply to comment #8) > >and now we can define home/end as line movement with caret browsing on. > I couldn't get this to work, even after tweaking platformHTMLBindings.xml Need another patch to get home/end work. Need hack browser-base.inc and platformHTMLBindings.xml. I'll post my patch to Bug 143996 soon.