Bug 200781 - after moving a tab with ctrl-shift-arrowkey focus moves to the location bar
Summary: after moving a tab with ctrl-shift-arrowkey focus moves to the location bar
Status: RESOLVED DUPLICATE of bug 159295
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-19 18:10 UTC by Marius
Modified: 2009-07-19 19:25 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Marius 2009-07-19 18:10:12 UTC 
Version:           4.2.4 (KDE 4.2.4) (using 4.2.4 (KDE 4.2.4), Gentoo)
Compiler:          i686-pc-linux-gnu-gcc
OS:                Linux (i686) release 2.6.30-gentoo-r1

After moving a tab left or right via the ctrl-shift-arrowkey combination, the focus moves to the location bar, and thus makes it impossible to move the tab more than one step left or right (by repeating the key combination) without mouse interaction.

Expected Behaviour:
The focus should stay where it was before pressing the key combination.
Comment 1 A. Spehr 2009-07-19 18:17:25 UTC 
Using 4.3.61, I can move it continuously.  So looks like this was fixed.
Or do you start with focus somewhere in particular?

Thanks!
Comment 2 Marius 2009-07-19 18:22:41 UTC 
I just focus the browsing area (or however the space below the tabs is called, where web pages etc. are displayed) by clicking at some empty space. This bug even occurs with empty tabs.
As I just noticed, it does not always occur after exactly one move, but sometimes I can move the tab several steps. But I could not find a pattern in when I can move one or more steps.
Comment 3 Marius 2009-07-19 18:24:09 UTC 
Hm, didn't want to close this bug ^^
Comment 4 Frank Reininghaus 2009-07-19 19:25:57 UTC 
Already reported, still reproducible for me in trunk.

*** This bug has been marked as a duplicate of bug 159295 ***