no. as you clean up directly all temp file/dir
NodeHelper is use in objecttreeparser too so you will delete directly.
And you will recreate old bug when we open attachment from an email and switch directly to another one without external application can be start.

So it's not the good fix here.

Well Otp only creates a NodeHelper if you don't give him an existing one. Looking through all cases NodeHelper/ObjectTreeParser is used:

• tests for templateparser, messageviewer, messagecomposer

-> they would benefit from the forceClean

• pim/messagelib/messagecomposer/src/composer/composerviewbase.cpp: MessageViewer::ObjectTreeParser otp(&emptySource); //All default are ok

-> using attachments but no files (KMime::Content)

• pim/messagelib/templateparser/src/templateparser.cpp: mOtp = new MessageViewer::ObjectTreeParser(mEmptySource);

->using attachments but no files (KMime::Content)

*pim/messagelib/messageviewer/src/utils/messageviewerutil.cpp: ObjectTreeParser otp(&emptySource, 0, 0, false, false);
->deactived code :D

• kdepim/kmail/editor/kmcomposewin.cpp: MessageViewer::ObjectTreeParser otp(&emptySource); //All default are ok

-> no handling of attachments

• pim/messagelib/messageviewer/src/viewer/viewer_p.cpp: mNodeHelper(new NodeHelper)

-> nodeHelper lives as long as the ViewerPrivate lives, and in the destructor of ViewerPrivate forceClean is triggerd
-> for just switching between mails still mNodeHelper->removeTempFiles(); so the delayed remove in that case is still possible.

So my conclusion is: we don't introduce the old bug back, but clean up in more cases.