Closed Bug 386189 Opened 17 years ago Closed 17 years ago

Cursor navigation by keyboard (arrow keys) does not work on designMode (including composer)

Categories

(Core :: DOM: Editor, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.9alpha8

People

(Reporter: jiha.bugzilla, Assigned: peterv)

References

()

Details

(Keywords: regression)

Attachments

(2 files, 2 obsolete files)

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
Keywords: regression
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.
Flags: blocking1.9?
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)
Flags: blocking1.9? → blocking1.9+
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
Attached patch v1 (obsolete) (deleted) — Splinter Review
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.
Assignee: nobody → peterv
Status: NEW → ASSIGNED
Attachment #272548 - Flags: superreview?(jst)
Attachment #272548 - Flags: review?(jst)
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[6]: *** [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.
Attached patch v1 (obsolete) (deleted) — Splinter Review
Forgot to diff again before attaching.
Attachment #272548 - Attachment is obsolete: true
Attachment #272617 - Flags: superreview?(jst)
Attachment #272617 - Flags: review?(jst)
Attachment #272548 - Flags: superreview?(jst)
Attachment #272548 - Flags: review?(jst)
Comment on attachment 272617 [details] [diff] [review] v1 Actually, this fails when mCurrentWindow is null.
Attachment #272617 - Flags: superreview?(jst)
Attachment #272617 - Flags: superreview-
Attachment #272617 - Flags: review?(jst)
Attachment #272617 - Flags: review-
nit: Peter, you should actually remove the flags instead of minusing it, since you was not the reviewer here.
Attached patch v1.1 (deleted) — Splinter Review
This one works reliably for me.
Attachment #272617 - Attachment is obsolete: true
Attachment #272645 - Flags: superreview?(jst)
Attachment #272645 - Flags: review?(jst)
Works here with patch v1.1 applied to CVS "checkout finish: Tue Jul 17 11:33:16 EDT 2007"
Attachment #272645 - Flags: superreview?(jst)
Attachment #272645 - Flags: superreview+
Attachment #272645 - Flags: review?(jst)
Attachment #272645 - Flags: review+
Thanks Peter, works great on linux for me.
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta1
Flags: in-testsuite?
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.
Attached patch Alternate approach (deleted) — Splinter Review
Attachment #274077 - Flags: review?(jst)
Attachment #274077 - Flags: superreview?(peterv)
Attachment #274077 - Flags: review?(jst)
Attachment #274077 - Flags: review+
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.
Attachment #274077 - Flags: superreview?(peterv)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: