After opening link in new tab that tab is background but steals focus. Reproducible: Always Steps to Reproduce: 1. Open any link in new tab (middle click or context menu item). Actual Results: At tab bar current tab doesn't change. And old page still visible. But toolbar describe status of new tab: stop button, url. Keyboard up/down scrolls hidden new tab. Expected Results: New tab should be fully background. Focus stealing is bad :) KDE SC/Konqueror 4.9.1 "release 561"
*** Bug 307286 has been marked as a duplicate of this bug. ***
This is caused by an unfortunate regression that made it into 4.9.1 release, but has already been addressed for the 4.9.2 release. See the link below for more details: https://bugs.kde.org/show_bug.cgi?id=304865#c8
Konqueror 4.9.2. Almost ok. But still exist for GMail (maybe some other). When opening https://mail.google.com/mail/ in background tab: 1. New tab is opened, tab color match "loading", all is ok. 2. Tab color becomes "loaded" (shortly), still ok. 3. Tab color again "loading", at this moment focus is stealed by gmail tab. 4. GMail tab finally loaded and has focus.
(In reply to comment #3) > Konqueror 4.9.2. Almost ok. But still exist for GMail (maybe some other). > When opening https://mail.google.com/mail/ in background tab: > 1. New tab is opened, tab color match "loading", all is ok. > 2. Tab color becomes "loaded" (shortly), still ok. > 3. Tab color again "loading", at this moment focus is stealed by gmail tab. > 4. GMail tab finally loaded and has focus. I cannot reproduce. At least not using konqueror + webkit browser engine. I clicked on the google mail link with the middle mouse button and everything happened as you specified above except the Tab loading again and then stealing the focus. Now the loading again can indeed happen because sites might do xmlhttp requests after they have already loaded a site, but if the tab is opened in the background, then it should not receive focus.
Strange… Happens every time for me.
Unable to reproduce with KHTML.
Konqueror+WebKit. Konqueror+KHTML doesn't open GMail (at least in my case).
Unable to reproduce with WebKit either. Gmail loads very quickly for me, and I go straight to your step 4 which, as I understand it, means there's no problem present.
(In reply to comment #7) > Konqueror+WebKit. Konqueror+KHTML doesn't open GMail (at least in my case). Wait I am a bit confused here. Just to be sure, can you explicitly specify the steps you followed to reproduce this issue everytime ? When I did the test I was either logged into gmail in another tab already or not logged into gmail at all. Testing this feature against Konqueror+khtml should be possible without logging into gmail first.
0. I have logged in GMail. 1. Open new tab https://mail.google.com/mail/ 2. It starts to load (progress bar is shown). 3. First stage loading ends. KHTML hangs here — loading stops, but nothing else happens. 4. GMail interface is shown, second stage loading begins. At this step focus is stealed. At step 2 I can switch to gmail tab and then to some other (my internet connection is rather slow). Anyway at step 3 gmail tab got input focus.
(In reply to comment #10) > 0. I have logged in GMail. > 1. Open new tab https://mail.google.com/mail/ > 2. It starts to load (progress bar is shown). > 3. First stage loading ends. KHTML hangs here — loading stops, but nothing else happens. > 4. GMail interface is shown, second stage loading begins. At this step focus is stealed. > > At step 2 I can switch to gmail tab and then to some other (my internet > connection is rather slow). Anyway at step 3 gmail tab got input focus. First this is a khtml specific issue because there is no problem logging into gmail using the webkit engine. However, I still do not understand how you are "logged in GMail" in step 0 when at step 3 you say nothing happens when you try to login to gmail using khtml. So how did you login into gmail in step 0 ?
I'm using webkit usually. And permanently logged into GMail (cookies), without need enter password. That's step 0.
Another use case have been found (kparts?): opening any pdf links in background. E.g. http://gcc.gnu.org/projects/cxx0x.html may be used for testing (webkit or khtml, both are affected).
(In reply to comment #13) > Another use case have been found (kparts?): opening any pdf links in > background. E.g. http://gcc.gnu.org/projects/cxx0x.html may be used for > testing (webkit or khtml, both are affected). I do not see any pdf links in that page. Perhaps I missed something. Anyhow, I have my own PDF links to test with [1] and I cannot reproduce the issue. [1] https://projects.kde.org/projects/extragear/base/kwebkitpart/repository/revisions/master/entry/tests/link_tests.html
Created attachment 74777 [details] E.g. N2761 is link to pdf. On screenshot: current tab is still C++11 gcc support, but toolbar and title correspond to "generalized attributes" pdf.
I confirm this in 4.9.2, with KHTML and WebKit.
Ok. I can reproduce that.
Hmm... this bug is very peculiar in that I can only reproduce it when the okular part has to be embedded into Konqueror. All the others I tried images (gwenview part), text documents (kate part) all seem to work correctly, i.e. they do not cause the focus to be put on the new tab opened in the background.
Git commit f1180645daa72b182f59a9b4099cb4612c73ea96 by Dawit Alemayehu. Committed on 26/10/2012 at 09:50. Pushed by adawit into branch 'KDE/4.9'. Prevent activation of tabs that were opened in the background. FIXED-IN: 4.9.3 REVIEW:107048 M +7 -1 konqueror/src/konqviewmanager.cpp http://commits.kde.org/kde-baseapps/f1180645daa72b182f59a9b4099cb4612c73ea96
4.9.3 has already been released, so it should be fixed in 4.9.4
Git commit 94177c6268898177aed9d2a1d97d50980f471fb2 by Dawit Alemayehu. Committed on 22/12/2012 at 05:10. Pushed by adawit into branch 'KDE/4.10'. Added setIgnoreExplictFocusRequests to correctly fix bug# 306714. See https://git.reviewboard.kde.org/r/107048/. REVIEW: 108017 M +17 -1 kparts/partmanager.cpp M +12 -0 kparts/partmanager.h http://commits.kde.org/kdelibs/94177c6268898177aed9d2a1d97d50980f471fb2
Git commit 506874cee8dff84fd136e1a378509f002eb9c1d6 by Dawit Alemayehu. Committed on 22/12/2012 at 15:43. Pushed by adawit into branch 'KDE/4.10'. Properly address the activation problem of tabs opened in the background. FIXED-IN: 4.10 RC2 (4.9.97) REVIEW: 107048 M +4 -2 konqueror/src/konqmainwindow.cpp M +5 -8 konqueror/src/konqviewmanager.cpp http://commits.kde.org/kde-baseapps/506874cee8dff84fd136e1a378509f002eb9c1d6
Bug is still partially present in 4.11.2. Opening a new tab with a PDF file, the new tab (as yet undisplayed) has focus, such that pressing Page Down in the original tab has no apparent effect, but instead has paged down the PDF file.
I can confirm that bug appears again on 4.11.2.
A good example for testing is http://ev.kde.org/reports.
Yes, the focus stealing portion has not been yet been addressed because it only happens with the pdf viewer (in this case the okular part) and none of the other KParts tested. The patch only fixed the incorrect activation of a background tab which should have of course fixed the focus stealing issue as well, but it does not for the okular part.
The focus problem with PDF documents embedded into a background tab in Konqueror is a okular kPart specific issue. It happens because the okular part explicitly steals the focus by calling "setFocus" in its kpart constructor. See https://projects.kde.org/projects/kde/kdegraphics/okular/repository/revisions/master/entry/part.cpp#L451 Hence that focus stealing issue has to be resolved there.
I can't see a reason to keep this open. Konqueror 5 doesn't open PDF in tabs (kinda fixed) and anyway it's effectively dead, isn't it?
I would not close as FIXED, then. Maybe INTENTIONAL. But Konqueror still opens PDF in tabs, if you have the kpart installed.
(In reply to Luigi Toscano from comment #29) > I would not close as FIXED, then. Maybe INTENTIONAL. Ok. I've tried to search something like "too old/not relevant" but failed :) UNMAINTAINED doesn't look fine. So, let it be INTENTIONAL. > But Konqueror still opens PDF in tabs, if you have the kpart installed. Well, I have `/usr/lib64/qt5/plugins/okularpart.so` but when I click with middle button on PDF link Konqueror opens new tab and shows dialog what to do with file (maybe some misconfiguration). When entering URL manually, pdf is opened inside of Konqueror, so kpart itself working. But anyway, I'm not using Konqueror anymore (moved to QupZilla->Falkon). And Konqueror is almost deprecated, am I wrong? Is anybody working on it? So if this bug would be relevant again anyone could reopen it, or open new for newer version. PS looked https://cgit.kde.org/konqueror.git/log/ and was surprised to see a lot of commits this month (unlike previous year).