Description of problem: XFCE: launching Konqueror from the menu, or command line, does not raise it. Yet: $ konqueror $ ps -ax | grep konqueror 9286 tty2 Sl+ 0:07 konqueror Note the lack of any O/P after the command, very rare. Konqueror starts fine under all other desktops tried. Version-Release number of selected component (if applicable): M7beta1 Classic ISO 2-4 Dec 2018, 5 desktop install. How reproducible: Every time. Steps to Reproduce: 1. Under XFCE, try starting Konqueror from menu or terminal.
Check you have the packages kio and kio-extras installed, i see some kpackages assume they will work on kde and don't have some requires
(In reply to katnatek from comment #1) > Check you have the packages kio and kio-extras installed, i see some > kpackages assume they will work on kde and don't have some requires Thanks, katnatek :-) @ Lewis Does installing those fix the issue?
CC: (none) => marja11Assignee: bugsquad => kdeSummary: Under XFCE, Konqueror does not start (M7beta1) => Under XFCE, Konqueror does not start (M7beta1) (missing dependencies?)
I will check for these pkgs when I get back to that M7/Classic installation. There are other fish to fry!
The plot thickens. (In reply to katnatek from comment #1) > Check you have the packages kio and kio-extras installed, i see some > kpackages assume they will work on kde and don't have some requires It was highly unlikely that these basic pkgs would not be present: $ rpm -q kio kio-5.51.0-1.mga7 $ rpm -q kio-extras kio-extras-18.08.3-1.mga7 $ rpm -q konqueror konqueror-18.08.3-1.mga7 Trying again under XFCE, the *first* time I launched Konqueror from the Internet menu - it started! Qutting it, it never appears again. Nor from the command line: $ konqueror $ However, as in comment 0: $ ps -ax | grep konqueror 9798 tty2 Sl+ 0:04 konqueror -session 27e430f17-6608-43b6-8ee1-2f1a0d90fca5_1544200102_455565 I must check this behaviour with other desktops. Will only report back if they are similar, rather than always starting it OK (which I believe at present).
Summary: Under XFCE, Konqueror does not start (M7beta1) (missing dependencies?) => Under XFCE, Konqueror does not re-start (M7beta1) (missing dependencies?)
is oxygen-icons5 installed ?
CC: (none) => mageia
GNOME It looks as if the problem is more widespread, not just Xfce. Altering bug title appropriately. Under Gnome, after a first successful launch, subsequent ones do nothing; but the console O/P is slightly different: $ konqueror Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. $ Will try this under other desktops. (In reply to Nicolas Lécureuil from comment #5) > is oxygen-icons5 installed ? [Yes] $ rpm -q oxygen-icons5 oxygen-icons5-5.51.0-5.mga7
Summary: Under XFCE, Konqueror does not re-start (M7beta1) (missing dependencies?) => Konqueror does not re-start (M7beta1) (missing dependencies?)
Problem also in MATE.
Progress. The problem exists under *all* desktops, Plasma included. It works like this: - The first time you start Konqueror, whether from menu or terminal, and kill its window in any normal way (File/Quit, Ctrl/Q, Alt/F4, click window X), the window closes but the process remains. Any subsequent attempt to re-start the application does not raise it. - If you kill its residual process, you can re-launch it. - If you start it from terminal, when the window is closed, the command remains extant: you do not return to the prompt. - If you break the command Ctrl/C, it really terminates; and you can then re-launch it from menu or terminal.
Had this behaviour for quite a long time. The same in Mageia 6 and in KDE neon. Did not report it, as the new KDE browser is Falkon, and there has been discussion weather to drop Konqueror altogether
CC: (none) => jyri2000
So it seems to be an upstream bug - konqueror just does not quit cleanly and the process remains running...
According KDE bug: https://bugs.kde.org/show_bug.cgi?id=388333 See also: https://forum.kde.org/viewtopic.php?f=309&t=142697
(In reply to Jüri Ivask from comment #9) > Had this behaviour for quite a long time. The same in Mageia 6 So it is! Shows how little Konqueror is used... (I do actually try it - but not repeatedly - when other browsers cause me grief with a site). > The new KDE browser is Falkon I had forgotten this. Naive question: are we going to include it in M7?
(In reply to Lewis Smith from comment #12) > So it is! Shows how little Konqueror is used... (I do actually try it - but > not repeatedly - when other browsers cause me grief with a site). You can try a workaround for this bug described here: https://forum.kde.org/viewtopic.php?f=309&t=142697#p383322 > > The new KDE browser is Falkon > I had forgotten this. Naive question: are we going to include it in M7? It's included (former qupzilla): http://svnweb.mageia.org/packages/cauldron/falkon/
(In reply to Jüri Ivask from comment #13) > You can try a workaround for this bug described here: > https://forum.kde.org/viewtopic.php?f=309&t=142697#p383322 Thanks for this pointer, which is is easy and effective: Settings-Configure Konqueror-Performance- DISable the 'Always try to have one preloaded instance' Quit Kill from a terminal all residual konqueror processes. Thereafter, you can indeed re-start Konqueror repeatedly; and when it quits, it really does. Is there any way this can be pre-configured? That would be ideal (-> Fixed). If not, this bug can be closed 'wontfix'. The solution is documented herein.
Summary: Konqueror does not re-start (M7beta1) (missing dependencies?) => Konqueror does not re-start
*** Bug 25123 has been marked as a duplicate of this bug. ***
CC: (none) => rod
Should be fixed with konqueror-19.04.0-1.1.mga7 in Core/Updates_testing repo disabling by default 'Always try to have one preloaded instance' option.
CC: (none) => geiger.david68210
This is great, David. I will try it as an update with the option reverted to as originally provided; curious as to whether it will need a re-instllation of Konqueror to be effective, since it is just a config change. Will report back. Bug 25337 is related.
======================== Packages in 7/core/updates_testing: ======================== konqueror-19.04.0-1.1.mga7.i586.rpm konqueror-handbook-19.04.0-1.1.mga7.noarch.rpm konq-plugins-19.04.0-1.1.mga7.i586.rpm libkf5konq6-19.04.0-1.1.mga7.i586.rpm libkonquerorprivate5-19.04.0-1.1.mga7.i586.rpm libkf5konq-devel-19.04.0-1.1.mga7.i586.rpm konqueror-19.04.0-1.1.mga7.x86_64.rpm konq-plugins-19.04.0-1.1.mga7.x86_64.rpm lib64kf5konq6-19.04.0-1.1.mga7.x86_64.rpm lib64konquerorprivate5-19.04.0-1.1.mga7.x86_64.rpm lib64kf5konq-devel-19.04.0-1.1.mga7.x86_64.rpm Source RPM: ======================== konqueror-19.04.0-1.1.mga7.src.rpm
Testing Mageia 7 x64 under Mate: BEFORE the update: Settings-Configure Konqueror-Performance- 'Always try to have one preloaded instance' SET by default. The problem is evident, Konqueror cannot be re-launched without killing all its residual processes. ------------------- AFTER the update: I only had/have 4 of all the pkgs listed above: lib64konquerorprivate5-19.04.0-1.1.mga7 konq-plugins-19.04.0-1.1.mga7 lib64kf5konq6-19.04.0-1.1.mga7 konqueror-19.04.0-1.1.mga7 I killed all residual Konqueror processes (left over from the 'before' test), after which Konqueror can be launched (menu, terminal) & killed by any means (File-Quit, Ctrl/Q, window X, Alt/F4) and *re-launched*. This happens even with Settings-Configure Konqueror-Performance- 'Always try to have one preloaded instance' still SET by default. Is this intended re Comment 16? It seems to render the option inoperable. So the DIY fix becomes unnecessary. @QA : I have assigned this to you, it should go through the normal update testing. Another test would be better. @DavidG : Can you please provide an advisory. It is possible that this update also fixes bug 25337, but that needs separate testing.
Assignee: kde => qa-bugsWhiteboard: (none) => MGA7-64-OK
Version: Cauldron => 7CC: (none) => tmb
Not working in 32-bit, on two separate M7 systems: Dell Inspiron 5100, 32-bit P4, 2GB RAM, Xfce-only system. Athlon X2, 8GB RAM, nvidia340 graphics, 32-bit Plasma system. The Dell was Xfce-only because Plasma doesn't play well with its ancient Radeon graphics. Installed the QArepo tool, Konqueror, and related dependencies - 220 packages in all. After, Konqueror exhibits the behavior Lewis reported. I updated Konqueror, but failed to kill all processes before trying it, and it didn't work. Rebooted, and it worked once. Rebooted again, checked the setting in question, and found the box was ticked. Unticked the box, and Konqueror works. Went back to the settings, clicked on the "Defaults" button, which ticked the box again, and Konqueror goes back to the old behavior. On the Athlon system, Konqueror had never been run that I can recall. I updated the Konqueror packages (same 4 that Lewis had) withoutrunning it, and rebooted, just to be sure that wasn't a factor. Ran the updated Konqueror, and checked the settings before doing anything else. The box was ticked. Unticked the box, hit "Apply." Hit the "Defaults" button, which ticked the box again. It acts as if nothing was done to the 32-bit version at all.
CC: (none) => andrewsfarm
Source RPM: (none) => konqueror
I just tried updating konqueror on a 64-bit Plasma-only system, and I'm seeing the same behavior that I saw with the 32-bit systems. Getting the update with no memory of ever using konqueror on this system, there was no change to the defaults. I unticked the box and hit Apply, then hit "Defaults," which set the box again. After Applying again, I was able to quit konqueror and restart - once. A second try was unsuccessful. I neglected to mention that I used the rpm list associated with this bug in the QArepo tool to select the packages to be updated. Removing the 64-bit OK, because it didn't work for me.
Whiteboard: MGA7-64-OK => (none)
Thank you TJ for looking at this - and finding a problem! > Removing the 64-bit OK, because it didn't work for me Fair enough. So I have had another go, konqueror-19.04.0-1.1.mga7 1. Start konqueror from cold; the 'pre-load' option is *ticked*, the old default. True for 1-4. $ ps -ax | grep konq 17533 ? Sl 0:05 konqueror 18733 ? S 0:00 file.so [kdeinit5] file local:/run/user/1001/klauncheruSenQB.1.slave-socket local:/run/user/1001/konquerorsyupAb.2.slave-socket The sub-process above x 5. 2. Kill it: $ ps -ax | grep konq 18733 ? S 0:00 file.so [kdeinit5] file local:/run/user/1001/klauncheruSenQB.1.slave-socket local:/run/user/1001/konquerorsyupAb.2.slave-socket The sub-process above x 5. So Konqueror itself has gone, but all the sub-processes remain. I am not happy about this, but it does not effect the issue. 3. Re-launch it. This *works*, 'ps' as in 1. 4. Kill it again; 'ps' as in 2. et seq 3-4 et seq. ------------------ Looking for a difference, I found after much playing around, that it all depends on using 'Defaults' to set the magic option; or doing it explicitly. AFTER the update, if you manipulate the option explicitly & alone, it has no effect and Konqueror always re-starts. Once you have set the option via 'Defaults', the old behaviour returns, Konqueror does nor re-start, its main process remains after quitting it (and must be killed before being able to re-start Konqueror at all). If you then unset the option & re-set it individually *not* using 'Default', Konqueror re-starts again even when it is set. @TJ: you can try that quickly. But I am handing this back to the KDE team, DavidG already CC'd.
Assignee: qa-bugs => kde
CC: (none) => tedguinan0982
CC: tedguinan0982, tmb => (none)