Closed Bug 386189 Opened 13 years ago Closed 13 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)
Duplicate of this bug: 386421
Flags: blocking1.9? → blocking1.9+
Duplicate of this bug: 387883
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
Duplicate of this bug: 388328
Attached patch v1 (obsolete) — 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) — 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.1Splinter 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: 13 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.
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.