Bug 153961 - textarea doesn't steal Ctrl-Shift-Right, tab is moved instead
Summary: textarea doesn't steal Ctrl-Shift-Right, tab is moved instead
Status: RESOLVED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: HI normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 165291 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-13 12:47 UTC by FiNeX
Modified: 2008-12-31 18:02 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description FiNeX 2007-12-13 12:47:03 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

Textfields in webpages allow to select text using the common shortucts: 
- SHIFT+LEFT/RIGHT ARROW : select one CHAR at a time
- CTRL+SHIFT+LEFT/RIGHT ARROW : select one WORD at a time

The CTRL+SHIFT+LEFT shortcut doesn't work in konqueror 4: instead of selecting words in the textfield, you could have this two behaviour:
A. the focus is switched to the address toolbar of konqueror and the selection is done in the address bar
B. do nothing.

This happen ONLY in textfield with multiple lines!
Comment 1 FiNeX 2008-04-21 13:55:44 UTC
Bug fixed on recent revisions :-)
Comment 2 Jakob Petsovits 2008-05-01 15:10:58 UTC
Nope, still doesn't work for me. I tried with today's SVN version, and though Ctrl-Shift-Left and -Right don't switch focus to the location edit (anymore), they move the tabs instead. Debugging shows that those key presses are not relayed to KTextArea::event(), which means it can't be accept()ed there.

I tried to find out what makes the TextAreaWidget fail when the LineEditWidget works, but KHTML is so object-oriented that I couldn't find out how it works with all this nesting of calls. I can't grok that without deeply immersing myself into the code, and I don't have the time for that currently.

So, could someone with more insight tell me when the events are propagated and when they're not? I'm convinced that it's a no-brainer if you know KHTML better than I do.
Comment 3 Jakob Petsovits 2008-05-01 15:13:57 UTC
Changing the title to be more specific.
Besides, did I mention that this is a blocker issue for me to switch to Konqueror 4?
Comment 4 FiNeX 2008-05-01 15:34:49 UTC
Confirmed. The bug is still reproducible on revision 802919. But I cannot reproduce ever. Sometimes it works right.
Comment 5 Jakob Petsovits 2008-05-01 15:38:54 UTC
The issue only manifests if there is a tab on the side that the current tab is being moved to. For example, if you've got two tabs and press Ctrl-Shift-Right on the left tab, that tab is being moved right. If you press the same shortcut on the right tab, KHTML is uninterested and selecting the word works.
Comment 6 FiNeX 2008-05-01 18:53:28 UTC
You're right. I can confirm it :-)
Comment 7 Jakob Petsovits 2008-05-27 13:38:12 UTC
Fixed by David Faure, with a patch that affects Qt itself. Apparently the issue was that some shortcut overrides were not specified, which otherwise would have caught the event instead of relaying it to KHTML/Konqueror.

The fix was sent to Trolltech, and I believe it was also applied to qt-copy. In QTextControl, consisted of just specifying a few more shortcut sequences to be caught for shortcut overrides.
Comment 8 monstermunch 2008-06-06 19:15:41 UTC
Confirmed in "KDE 4.00.80 (KDE 4.0.80 >= (KDE 4.1 Beta1)" in kubuntu
Comment 9 FiNeX 2008-09-27 10:42:00 UTC
It seems that the bug is not fixed in 4.1.1
Comment 10 Roland Leißa 2008-10-07 19:43:16 UTC
Still not working here (kde 4.1.2). Perhaps an update of Qt could solve the problem. I am currently doing an update.
Comment 11 FiNeX 2008-12-09 16:09:44 UTC
Fixed in current trunk r894724 with Qt 4.4.3.
Comment 12 Dario Andres 2008-12-31 18:02:32 UTC
*** Bug 165291 has been marked as a duplicate of this bug. ***