Bug 363273 - Kate sometimes loses edit panel when switching sessions
Summary: Kate sometimes loses edit panel when switching sessions
Status: RESOLVED DUPLICATE of bug 358266
Alias: None
Product: kate
Classification: Applications
Component: application (show other bugs)
Version: unspecified
Platform: Other Linux
: HI crash
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-19 12:02 UTC by Nick Coghlan
Modified: 2016-09-07 15:27 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Katesession file with no edit panel (3.04 KB, text/plain)
2016-06-07 16:50 UTC, Nick Coghlan
Details
Working katesession (2.61 KB, text/plain)
2016-06-07 17:00 UTC, Nick Coghlan
Details
Buggy anonymous.katesession (11.96 KB, text/plain)
2016-08-12 15:04 UTC, Alan Robinson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Coghlan 2016-05-19 12:02:31 UTC
When switching sessions, the main edit panel sometimes disappears from the Kate window, and quitting and restarting Kate doesn't bring it back. All of the other window elements appear to be present, just the actual text editing panel itself is missing (replaced by a plain grey unadorned space).

When Kate gets itself into that state, the only thing that seems to fix it is logging out and restarting the entire KDE session.

Reproducible: Sometimes

Steps to Reproduce:
1. Have Kate open in a saved session
2. Use the quick open session menu option to switch to a different session


Actual Results:  
Sometimes the new session opens without an edit panel, and Kate is stuck that way until KDE is started

Expected Results:  
The new session opens normally

Marking as a crash, since even though the overall application is technically still running, it's unusable until the KDE sessions is restarted.
Comment 1 Nick Coghlan 2016-05-23 05:58:04 UTC
This seems to have now progressed to Kate simply not creating the edit panel when opening an existing session, even on a fresh login. This problem then persists even if opening a new session. (I've turned off SELinux and the behaviour persists, so it isn't anything related to that).

Running Kate from a console window, I get this output:

==================
$ kate &
$ QObject::connect: invalid null parameter
QObject::connect: invalid null parameter
QObject::connect: Cannot connect (null)::returnPressed() to KUrlRequester::returnPressed()
QObject::connect: Cannot connect (null)::returnPressed(QString) to KUrlRequester::returnPressed(QString)
Attempted to re-run an already running session.
QObject::connect: invalid null parameter
QObject::connect: invalid null parameter
QObject::connect: Cannot connect (null)::returnPressed() to KUrlRequester::returnPressed()
QObject::connect: Cannot connect (null)::returnPressed(QString) to KUrlRequester::returnPressed(QString)
Attempted to re-run an already running session.
Attempted to re-run an already running session.
==================

The first "Attempted to re-run..." is from choosing a session at start-up, the second pair is from an attempt to switch sessions.
Comment 2 Nick Coghlan 2016-06-04 17:27:11 UTC
It's looking like the problem may be specific to something in the saved session state - I deleted the anonymous session state from ~/.local/share/kate/anonymous.katesession and new sessions are working properly again, while the behaviour of existing sessions depends on which session I start with.

Is there specific setting I can check that might be a potential culprit? I tried diffing a working session against a broken one, but there was too much noise from the actual differences in the opened files for me to spot anything that might potentially be significant.
Comment 3 Nick Coghlan 2016-06-04 17:32:07 UTC
I just noticed I hadn't reported the Kate version affected:

$ kate -v
kate 16.04.1
$ rpm -qa kate
kate-16.04.1-1.fc24.x86_64
Comment 4 Dominik Haumann 2016-06-05 08:03:55 UTC
Can you attach a minimalistic .katesession file that has this issue?
I have once seen this as well...
Comment 5 Nick Coghlan 2016-06-07 16:50:39 UTC
Created attachment 99402 [details]
Katesession file with no edit panel

"broken.katesession" is edited down from a session that had lost its edit panel.

I did the same thing with a session that was still working (which I'll upload in a moment), and the most suspicious part of the diff was this section:

 [MainWindow0-Splitter 0]
-Children=MainWindow0-ViewSpace 0
+Children=MainWindow0-Splitter 1,MainWindow0-Splitter 2,MainWindow0-Splitter 3,MainWindow0-Splitter 4,MainWindow0-ViewSpace 0
 Orientation=1
-Sizes=1758
+Sizes=0,0,0,0,0

Setting aside the multitude of splitters, the broken session has Size 0 for the ViewSpace.
Comment 6 Nick Coghlan 2016-06-07 17:00:55 UTC
Created attachment 99403 [details]
Working katesession

Based on the diff between the broken session and this working session, I tried changing the Splitter 0 definition in the broken session to:

[MainWindow0-Splitter 0]
Children=MainWindow0-Splitter 1,MainWindow0-Splitter 2,MainWindow0-Splitter 3,MainWindow0-Splitter 4,MainWindow0-ViewSpace 0
Orientation=1
Sizes=0,0,0,0,1665

The only change was to force the ViewSpace to a non-zero size, which was enough to bring the edit panel back.

Running grep over my session files then suggests that the problem is consistently:

- MainWindow0-Splitter 0 has ended up with multiple children (generally ViewSpace 0 + other splitters)
- the Sizes of all children, including the ViewSpace, have been set to zero

So, as a workaround, going into the session file and fixing that manually seems to do the trick.

However, it doesn't explain how the incorrect setting is getting into the session file in the first place.
Comment 7 Dominik Haumann 2016-06-14 07:28:14 UTC
If the mainwindow is empty, there in fact is a splitter that can be dragged which makes the editing widgets appear again. The splitter is either on the left or the right.

I added a workaround for the Applications 16.08 release that removes hidden/invisible editing areas. By default if all are hidden, we should still get one editing area. I won't backport to 16.04, though, since I am not sure it might introduce regressions.

And yes, the issues is indeed the "Sizes=0,0,...". The remaining question is now: How are these 0,0,... introduces in the first place? Because this is the real bug, which is still not fixed.

If you find that out (I already tried quite a bit), that would be really cool.
Comment 8 Alan Robinson 2016-08-12 15:03:33 UTC
I have been experiencing this bug using kate 16.04.2, and possibly earlier versions.  The bad split pane size originates from the anonymous.katesession file.  The bad settings are contagious when opening new sessions.  I.e. if I start a new session in kate, the edit pane disappears.  If I then open an existing session, the bad edit pane settings are preserved from the first session, and are saved to each subsequently opened session.
Comment 9 Alan Robinson 2016-08-12 15:04:58 UTC
Created attachment 100562 [details]
Buggy anonymous.katesession

Source of buggy settings leading to a missing edit pane.
Comment 10 Nick Coghlan 2016-08-18 06:38:26 UTC
After manually cleaning up all my broken session files a while ago, I managed to break a couple of them again today by doing:

- start Kate, selecting a particular session from the pop-up window (no problem)
- use Sessions->Quick Open Session to switch to a different session (no problem)
- use Sessions->Quick Open Session to switch back to the original session (problem)

At that point, the original session had no edit panel. I hand-edited the session file, and restarted Kate, and it was working again. However, switching to the other session showed that it had *also* acquired the bad settings, and switching back to the original session again also recreated the problem there.

After doing that a couple more times, here's what the "MainWindow0-Splitter 0" section looked like:

[MainWindow0-Splitter 0]
Children=MainWindow0-Splitter 1,MainWindow0-Splitter 2,MainWindow0-Splitter 3,MainWindow0-Splitter 4,MainWindow0-Splitter 5,MainWindow0-Splitter 6,MainWindow0-Splitter 7,MainWindow0-Splitter 8,MainWindow0-Splitter 9,MainWindow0-Splitter 10,MainWindow0-Splitter 11,MainWindow0-Splitter 12,MainWindow0-Splitter 13,MainWindow0-Splitter 14,MainWindow0-Splitter 15,MainWindow0-Splitter 16,MainWindow0-ViewSpace 0
Orientation=1
Sizes=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

Meanwhile, the other session (the one I was switching *to* each time, before switching back to the original) looked like:

[MainWindow0-Splitter 0]
Children=MainWindow0-Splitter 1,MainWindow0-Splitter 2,MainWindow0-Splitter 3,MainWindow0-Splitter 4,MainWindow0-Splitter 5,MainWindow0-Splitter 6,MainWindow0-Splitter 7,MainWindow0-Splitter 8,MainWindow0-Splitter 9,MainWindow0-Splitter 10
Orientation=2
Sizes=0,0,0,0,0,0,0,0,0,0

So it seems something is going wrong with the splitter and viewspace definitions when switching back and forth between sessions (in case its relevant - each of the two sessions has 30-60 files currently open, but more than that recorded in the session file)
Comment 11 Nick Coghlan 2016-08-18 06:43:22 UTC
Updated version info, since Fedora's pushed a few updates through since I first encountered this issue:

$ rpm -qa kate
kate-16.04.3-1.fc24.x86_64
Comment 12 Christoph Cullmann 2016-09-07 15:27:45 UTC
=> Fixed post 16.04, should be in current 16.08 release, see bug 358266

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