I can reproduce the crash with the provided steps here using:

Qt: 4.5.2 (KDE-Qt git commit f9802f2bbbd23137acb5f80d1f131fa6b1a85752
        Date:   Fri Jun 12 15:06:29 2009 +0200)
KDE: 4.3.62 (KDE 4.3.62 (KDE 4.4 >= 20090728))
kdelibs svn rev. 1006918 / kdebase svn rev. 1006918
on ArchLinux i686 - Kernel 2.6.30.4

Getting the same backtrace.
Thanks

*** Bug 192516 has been marked as a duplicate of this bug. ***

Could this be a dup of bug #197836 ?

(In reply to comment #3)
> Could this be a dup of bug #197836 ?

I have checked it and even when the summary is related the backtrace is not so I would choose to keep them separated. Regards

Seems to be a regression caused by my fix for bug 174292 - sorry about that! I promise to have a thorough look at this before KDE 4.3.3.

It does not crash if the tab that is broken off contains split views.

Created attachment 37441 [details]
Possible fix (not very elegant) and new unit tests

Some remarks about my patch:

1. In KonqViewManager::breakOffTab, it seems that KonqViewManager::loadViewProfileFromConfig (which was there before my fix for bug 174292) works well for tabs which are not split, and KonqViewManager::loadRootItem (with the tab container as the parent) works fine for split views. I don't know the internals of KonqViewManager well enough to understand why - maybe there is actually a bug in either of these functions which I haven't seen yet.

2. The patch contains unit tests for the two "break off tab" issues and for bug 160407.

3. I suggest to change the return type of KonqViewManager::breakOffTab and return the new main window. Without this change, unit testing the present bug seems difficult to me.

The unit test looks good, the API change is certainly fine; but the fix itself looks a bit strange indeed, I think it hides a bug somewhere.

SVN commit 1032808 by dfaure:

Allow to focus readonly form elements (like other browsers do, partial revert of the commits for 159682),
which makes it possible to copy their text, too (for tomj on irc).
On the other hand, don't allow Ctrl+X and Ctrl+V to work in such widgets.
Will backport for 4.3.3.
BUG: 203069
CCBUG: 159682


 M  +1 -1      html/html_formimpl.cpp  
 M  +18 -12    khtml_ext.cpp  
 M  +2 -2      rendering/render_form.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1032808

Gahh wrong bug number.

(for future reference, comment #8 was about bug 190188)

*** Bug 209763 has been marked as a duplicate of this bug. ***

Maybe I got a bit closer to the hidden real bug: If I revert my fix for bug
174292 (except for the change to KonqMainWindow which I believe is correct),
breaking off split tabs leads to a crash because no tab container is created
for the new main window. In KonqViewManager::setLoading(), which is called
indirectly from KonqViewManager::loadItem(), the setLoading() method of the
NULL m_tabContainer is called.

[My fix for that bug worked because it calls
mainWindow->viewManager()->tabContainer() in KonqViewManager::breakOffTab(),
which creates the tab container.]

The reason why it works if the tab is not split is that the "View" branch of
KonqViewManager::loadItem() contains the code (added in r673169)

if ( parent == m_pMainWindow )
    parent = tabContainer();

which creates the tab container. The "Container" branch contains no such code.
I tried to add these two lines also in that branch, but then two problems
remain:

1. Because of the fix for bug 203166 it still crashes because that makes
loading one container with two views via loadViewProfileFromConfig()
impossible.

2. This change would breaks loading the file management profile because that
contains a container with tabs as a child -> everything gets messed up because
the tab container is then both the parent and the child of the
KonqFrameContainer.

So far, I couldn't find a good way to initialise the tab container without
breaking other things :-( The alternative approach would be to not revert my
fix for bug 174292 (such that the tab container gets created properly) and try
to find out why replacing loadViewProfileFromConfig() by loadRootItem() broke
breaking off tabs without split views...

The cause of the crash in this bug report seems to be that the "active child" of the tab container of the new main window is 0 after the tab is broken off. Before my fix for bug 174292, this was not the case because KonqViewManager::loadViewProfileFromGroup() calls setActivePart(), which indirectly sets the active child via KonqViewManager::slotActivePartChanged().

If the tab is split, this problem does not occur: In the "Container" branch of KonqViewManager::loadItem(), the setActiveChild() method of the container is called, which also sets the active child of its parent, i.e., the tab container, in the line

m_pParentContainer->setActiveChild( this ).

Therefore, a possibility to fix this would be to make sure that the only child of the tab container is also its active child :-)

Created attachment 37484 [details]
New patch

This patch makes sure that the tab container of the new window in KonqViewManager::breakOffTab() has an active child. There are also other ways (like calling setActivePart(), maybe that's better?).

I've also made two small changes to the unit tests:

1. Verify that the tab container has an active child, such that the test fails earlier.

2. Delete the new main windows.

Created attachment 37600 [details]
Updated patch (also fixes and unit-tests bug 210686)

Frank: excellent analysis, thanks for that.

Now that I understand the problem ;) I wonder if simply doing
mainWindow->viewManager()->loadViewProfileFromConfig( config, QString(), currentProfile() );
in all cases would solve it? I.e. not creating the tabContainer until needed, like we do in all other cases (new window etc.). But I guess I need to re-read the file a bit more to check if we always set an active child when we create the tabContainer everywhere.

(In reply to comment #16)
> I wonder if simply doing
> mainWindow->viewManager()->loadViewProfileFromConfig( config, QString(),
> currentProfile() ); in all cases would solve it?

No, it would not - it was like that before I tried to fix bug 174292. In that case, no tab container is created for split views (see comment 12).

Ah I see. The tab container is not really created on demand, but created already when the first view is created (in the normal case; cf createFirstView).

It seems to me that the two openSavedWindow methods have that same problem too. 

OK. Which leads me to something else:
as you said, loadItem takes care of this for the other cases (profiles with a tab container or splitted views, not just for a single frame). So I think it would be more logical and easier to understand/maintain if loadItem also took care of setting the active child in the case of a single frame. It would be less surprising for the caller of loadRootItem, and would fix all cases where we currently end up with no active child.

I'll test http://www.davidfaure.fr/2009/konqviewmanager.cpp.diff with your unittest ;)

It broke other tests due to tabContainer() instead of m_tabContainer, works now. (It was creating the tab container too early when e.g. loading a profile with a sidebar).

New diff for konqviewmanager.cpp (including your changes)
http://www.davidfaure.fr/2009/konqviewmanager.v2.diff

All unittests (including the ones you added) pass with this patch.

Looks ok to you?

I can't test it now because I'm not at home, but the updated patch looks good to me :-) It looks like that should work in any case (at least the ones we've seen so far).

Do you want to commit it with the new unit tests, or shall I do it (could do it tonight)?

SVN commit 1036042 by dfaure:

Fix "Adding tab (Ctrl+T) in detached (tab) window crashes Konqueror".
Excellent investigation, unit-test, and suggested fixes by Frank Reininghaus.
Will backport for 4.3.3.
BUG: 203069


 M  +11 -2     konqviewmanager.cpp  
 M  +3 -2      konqviewmanager.h  
 M  +60 -0     tests/konqviewmgrtest.cpp  
 M  +2 -0      tests/konqviewmgrtest.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1036042