Version: unspecified (using KDE 4.4.2) OS: Linux When I open a PDF file by following a link on a web page or typing it into the URL bar, the viewer is opened but not given the input focus so that keyboard cannot be used to scroll it (i.e., Space, PgUp/Dn, etc). The same thing happens when switching tabs, even when the viewer used to have the focus and I just briefly switched to the next tab and back again to the original one. The extra click needed to get the keyboard scrolling into the viewer really breaks the flow and makes Konqueror as bad as Firefox in lack of a smooth overall experience. This did not use to be the case with KDE 3.5, where the keyboard focus was always given to the embedded viewer so that it could be used immediately. Reproducible: Always OS: Linux (i686) release 2.6.32-22-generic Compiler: cc
This is similar to bug 214020, which reports that when OkularPart is opened in Kile, it does not get the input focus. Could be the same reason is behind the PDF embedded viewer's not getting the focus in Konqueror.
(In reply to comment #1) > This is similar to bug 214020, which reports that when OkularPart is opened in > Kile, it does not get the input focus. Could be the same reason is behind the > PDF embedded viewer's not getting the focus in Konqueror. Yes this is the same thing as 214020. Other parts such as the text editor part correctly receive focus. This is an issue in the okular kpart.
Git commit 6176e29256eb417d76d898955d5345ce340d1384 by Albert Astals Cid. Committed on 16/12/2011 at 00:25. Pushed by aacid into branch 'master'. Use a queued connection instead of direct call It seems some shells (like konqueror and kile) are too smart and play with the focus and the focus ends up in the wrong place because they "overwrite" our setFocus call, now we workaoround that by using the queuedconnection BUGS: 214020 BUGS: 240516 FIXED-IN: 4.8.0 M +1 -1 part.cpp http://commits.kde.org/okular/6176e29256eb417d76d898955d5345ce340d1384