Closed Bug 386189 Opened 14 years ago Closed 14 years ago
Cursor navigation by keyboard (arrow keys) does not work on design
Mode (including composer)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070628 Mnenhy/0.7.5.0 SeaMonkey/2.0a1pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070628 Mnenhy/0.7.5.0 SeaMonkey/2.0a1pre no navigation with $arrowkey or ctrl+$arrowkey Reproducible: Always Steps to Reproduce: 1. Open Composer 2. input some words/lines 3. try to use the arrow keys on edited text Actual Results: nothing happens. Cursor is not moved. Expected Results: Cursor should be moved word wise by using ctrl+$arrowkey or character wise by using $arrowkey. bug appears with this build: cvs checkout start: Do 2007-06-28 14:26:11 CEST (+0200) (should be 5:26 PDT) it did not appear with that build: cvs checkout start: Mi 2007-06-27 11:06:27 CEST (+0200) Maybe this is fallout from bug 237964 for bug 386009 See http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-27+02%3A00%3A00&maxdate=2007-06-28+05%3A00%3A00&cvsroot=%2Fcvsroot
I would bet it's due to bug 237964, due the bug 237964 comment 0, by Glazman. Can confirm on a SeaMonkey build using the mail composer, as of some hours ago.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(this is from bug 237964) ==> editor
Assignee: composer → nobody
Component: Composer → Editor
Product: Mozilla Application Suite → Core
QA Contact: editor
Version: unspecified → Trunk
Cursor navigation also no longer works in any vBulletin reply form, which uses designMode.
Copy & Paste also does not work. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070702 Minefield/3.0a6pre - Build ID: 2007070204
See URL for another testcase: http://www.mister-pixel.com/ever/bugs/firefox/content_editable_testcase2.237964.html Neither Control+C, Control+V, Home, End, PageUp or PageDown works.
Summary: Cursor navigation by keyboard (arrow keys) does not work in composer → Cursor navigation by keyboard (arrow keys) does not work on designMode (including composer)
Did this get fixed somehow? With a trunk build from today, I go to http://www.mozilla.org/editor/midasdemo/ and enter a bunch of words. I can then navigate with the keyboard without problem, shortcuts for copy and paste work too. Same with the vBulletin demo site (http://www.vbulletin.com/admindemo.php). Same with message compose in a Thunderbird trunk build from today.
doesn't work for me with http://www.mozilla.org/editor/midasdemo/. DOES work with the vbulletin demo. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007071304 Minefield/3.0a7pre - Build ID: 2007071304
Anyone seeing this and not on Linux?
Just did a fresh linux build after seeing your 12:11 posting. The vbulletin demo also wfm but the midasdemo does not. No change in mail/news compose.
Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a7pre) Gecko/200707132020 SeaMonkey/2.0a1pre Updated 2 hours ago... It does not work for me on either midas or Vbulletin demo.
WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071506 Minefield/3.0a7pre
I just compiled the trunk version of Thunderbird on Linux and the arrow keys do not work. Here are the build options I used: . $topsrcdir/mail/config/mozconfig export MOZILLA_OFFICIAL=1 export BUILD_OFFICIAL=1 mk_add_options MOZILLA_OFFICIAL=1 mk_add_options BUILD_OFFICIAL=1 ac_add_options --enable-official-branding mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/thunderbird-bin ac_add_options --enable-default-toolkit=cairo-gtk2 ac_add_options --with-user-appdir=.mozilla #ac_add_options --with-system-png=/usr ac_add_options --with-system-jpeg=/usr ac_add_options --enable-postscript ac_add_options --disable-installer ac_add_options --disable-xprint ac_add_options --enable-crypto ac_add_options --enable-strip-libs ac_add_options --enable-canvas ac_add_options --enable-svg ac_add_options --enable-mathml ac_add_options --disable-tests ac_add_options --disable-gtktest ac_add_options --disable-debug ac_add_options --enable-xft ac_add_options --enable-optimize="-O4 -march=opteron -mtune=opteron -pipe -ftracer -fomit-frame-pointer -msse3" ac_add_options --with-system-zlib=/usr ac_add_options --without-system-nspr ac_add_options --enable-xinerama ac_add_options --enable-extensions=default ac_add_options --disable-pedantic ac_add_options --disable-long-long-warning ac_add_options --enable-single-profile ac_add_options --disable-profilesharing ac_add_options --enable-gnomevfs ac_add_options --disable-updater
We started focussing editable elements (contentEditable or the documentElement of editable documents), so we need to return the window's controllers for those elements in nsFocusController::GetControllers.
Perhaps I tried this prematurely. I patched my CVS pull from "checkout finish: Sat Jul 14 17:51:56 EDT 2007" after a distclean and received the following: /mozilla/dom/src/base/nsFocusController.cpp: In member function 'virtual nsresult nsFocusController::GetControllers(nsIControllers**)':/mozilla/dom/src/base/nsFocusController.cpp:267: error: 'class nsDerivedSafe<nsIDOMElement>' has no member named 'IsEditable' gmake: *** [nsFocusController.o] Error 1
Comment on attachment 272548 [details] [diff] [review] v1 >+ nsCOMPtr<nsIContent> content = do_QueryInterface(mCurrentElement); I suspect that the rest of the |mCurrentElement| should be |content|. That compiles, but unforunately does not seem to help with this bug.
Forgot to diff again before attaching.
Comment on attachment 272617 [details] [diff] [review] v1 Actually, this fails when mCurrentWindow is null.
nit: Peter, you should actually remove the flags instead of minusing it, since you was not the reviewer here.
This one works reliably for me.
Works here with patch v1.1 applied to CVS "checkout finish: Tue Jul 17 11:33:16 EDT 2007"
Thanks Peter, works great on linux for me.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta1
I'm not sure this is the correct fix. By my LXRing the only caller of nsFocusController::GetControllers is nsXBLWindowKeyHandler and it looks to me as if that should prefer to call nsFocusController::GetControllerForCommand directly so that GetControllers could be made private to nsFocusController.
Comment on attachment 274077 [details] [diff] [review] Alternate approach Neil: is this patch trying to fix something or is it just cleanup that's unrelated to the bug?
Comment on attachment 274077 [details] [diff] [review] Alternate approach Clearing stale request, question in bug never addressed.
You need to log in before you can comment on or make changes to this bug.