Bug 306417 - opened new tab becomes active though not visible
Summary: opened new tab becomes active though not visible
Status: RESOLVED INTENTIONAL
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
: 307286 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-09-07 18:38 UTC by Mykola Krachkovsky
Modified: 2019-02-01 16:04 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.10 RC2 (4.9.97)


Attachments
E.g. N2761 is link to pdf. (54.80 KB, image/png)
2012-10-24 15:24 UTC, Mykola Krachkovsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mykola Krachkovsky 2012-09-07 18:38:40 UTC
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"
Comment 1 Dawit Alemayehu 2012-09-25 07:50:17 UTC
*** Bug 307286 has been marked as a duplicate of this bug. ***
Comment 2 Dawit Alemayehu 2012-09-25 07:57:16 UTC
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
Comment 3 Mykola Krachkovsky 2012-10-06 10:30:38 UTC
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.
Comment 4 Dawit Alemayehu 2012-10-06 13:54:52 UTC
(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.
Comment 5 Mykola Krachkovsky 2012-10-06 15:29:58 UTC
Strange… Happens every time for me.
Comment 6 Graeme Hewson 2012-10-06 16:02:56 UTC
Unable to reproduce with KHTML.
Comment 7 Mykola Krachkovsky 2012-10-06 16:25:43 UTC
Konqueror+WebKit. Konqueror+KHTML doesn't open GMail (at least in my case).
Comment 8 Graeme Hewson 2012-10-06 16:50:51 UTC
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.
Comment 9 Dawit Alemayehu 2012-10-06 21:50:46 UTC
(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.
Comment 10 Mykola Krachkovsky 2012-10-07 08:44:42 UTC
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.
Comment 11 Dawit Alemayehu 2012-10-07 23:41:41 UTC
(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 ?
Comment 12 Mykola Krachkovsky 2012-10-08 14:34:38 UTC
I'm using webkit usually. And permanently logged into GMail (cookies), without need enter password. That's step 0.
Comment 13 Mykola Krachkovsky 2012-10-24 12:23:09 UTC
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).
Comment 14 Dawit Alemayehu 2012-10-24 14:29:05 UTC
(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
Comment 15 Mykola Krachkovsky 2012-10-24 15:24:29 UTC
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.
Comment 16 Graeme Hewson 2012-10-24 15:38:12 UTC
I confirm this in 4.9.2, with KHTML and WebKit.
Comment 17 Dawit Alemayehu 2012-10-24 16:36:30 UTC
Ok. I can reproduce that.
Comment 18 Dawit Alemayehu 2012-10-25 22:15:36 UTC
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.
Comment 19 Dawit Alemayehu 2012-11-15 16:10:01 UTC
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
Comment 20 Jekyll Wu 2012-11-15 16:55:01 UTC
4.9.3 has already been released, so it should be fixed in 4.9.4
Comment 21 Dawit Alemayehu 2013-01-03 06:06:21 UTC
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
Comment 22 Dawit Alemayehu 2013-01-03 06:32:11 UTC
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
Comment 23 Graeme Hewson 2013-10-19 16:02:01 UTC
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.
Comment 24 Mykola Krachkovsky 2013-10-20 06:09:47 UTC
I can confirm that bug appears again on 4.11.2.
Comment 25 Graeme Hewson 2013-10-20 06:53:34 UTC
A good example for testing is http://ev.kde.org/reports.
Comment 26 Dawit Alemayehu 2014-02-22 15:48:55 UTC
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.
Comment 27 Dawit Alemayehu 2014-06-14 21:02:43 UTC
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.
Comment 28 Mykola Krachkovsky 2019-01-31 20:57:08 UTC
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?
Comment 29 Luigi Toscano 2019-01-31 21:02:03 UTC
I would not close as FIXED, then. Maybe INTENTIONAL. But Konqueror still opens PDF in tabs, if you have the kpart installed.
Comment 30 Mykola Krachkovsky 2019-02-01 16:04:04 UTC
(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).