Description: CRASH: When closing the document before handling the warning about pasting data into cells that already contain data (not quite likely to happen, I suppose) Steps to Reproduce: 1. Open the attached file 2. Copy for example the cell content of A5-C26 3. Select cell E5 and paste 4. Ignore the warning; close the document; dont'save 5. Now press Yes/NO in the Warning dialog -> CRASH Actual Results: Crash Expected Results: No Crash Reproducible: Always User Profile Reset: No Additional Info: Version: 6.0.0.0.alpha0+ Build ID: c5a93cad149618bbd43632f1660a558c34bdbf7e CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-10-07_01:04:25 Locale: en-US (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 137019 [details] Example file
On pc Debian x86-64 with master sources updated today, I could reproduce this. Eike: shouldn't the warning message popup be modal so we shouldn't be able to close the document before having responded?
Created attachment 137020 [details] bt with debug symbols
Regression introduced by: author Armin Le Grand <Armin.Le.Grand@cib.de> 2017-08-24 16:32:38 (GMT) committer Armin Le Grand <Armin.Le.Grand@cib.de> 2017-08-25 09:31:42 (GMT) commit db6b703d391838c481fd090065f6d329edcd4efa (patch) tree c17b58ca1f9e0f0beaa3b1b5c89d0e85bdaedaf7 parent 69cfafef7a28aad7a013bb440e15e23e59ea628c (diff) Allow non-modal Dialogs during FileImport/Load When opening a file that triggers Dialogs (e.g. cannot read/repair/FileType) the Frame from which it was initialized gets blocked. This irritates quite some people. Changed this to a non-modal Dialog so that the user can continue to work with all opened docs, open new ones, close and print/PDF/export these. Bisected with: bibisect-linux64-6.0 Adding Cc: to Armin Le Grand
Not sure what the original problem was, but it may have been that the problem to be solved was to ensure that the parents of message dialogs were explicitly set to the window they should block (instead of null to select a default parent) rather than making dialogs non-modal
Created attachment 137480 [details] Screencast (In reply to Caolán McNamara from comment #5) > Not sure what the original problem was, but it may have been that the > problem to be solved was to ensure that the parents of message dialogs were > explicitly set to the window they should block (instead of null to select a > default parent) rather than making dialogs non-modal Still a repro... Attached a screencast to make things clear..
caolanm->telesto: sorry, I meant the problem that the commit that made these dialogs non-modal wanted to fix, I was speculating that the wrong parent might have been autodetected and another solution might be to set an explicit parent.
have a solution here that seems to work
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fdcd11ff68fcd9e46aad6efc20779a063f4f6182 Resolves: tdf#113160 changing all warning dialogs to non-modal is unsafe It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a09ca614bcf07fadddeecb217f0c871f084810c Related: tdf#113160 set parent of warning dialogs during load It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 6.0.0.0.alpha1+ Build ID: 5e0022c90c4125a1590b3688dfec73c271b7aedd CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group
@Caolán: Thanks for taking care so far. The initial problem happens when opening a doc that immediately triggers a dialog at load time. There *is* no window at load time, so this blocks the whole office with a single modal dialog. I thought about 'forcing' the office to open a win and view for the doc in loading state, but could not find a way to do so. Since of course the initial problem is back, do you have suggestions...?
Can you give me a sample document for that. Perhaps we can force explicit parents for the specific dialog(s) and explicitly force disable-pick-auto-parent for it/them
Created attachment 137889 [details] File that produces a dialog on opening and cannot be repaired Took a while - had to create an own file due to the orig being from customer. It triggers the same dialog now when trying to open. So: - Try to open - when dialog is open, it's not possible to work with office anymore - try repair -> new dialog - same state: not possible to work with office Customer wants to be able to continue work on open docs, esp. save them or similar. Possible for all except the one where you started to open the new doc. That one is blocked (of course), but from user's view this is not logical (in contrary to us who know what happens and why it's blocked). BG seems to be that some users (sigh) 'forget' that (non-huge) dialog or move it to some place where they see it no longer.
Created attachment 137891 [details] A GereralError dialog By pure coincidence I just produced the attached dialog. That one did not block any of the three open docs, I could close them all and office still running with only that dialog remaining. Do not know how to reproduce. Problem is that after closing that dialog the office does not terminate, keeps running as task.
That is more or less what I wanted to achieve with the original change, plus the working office termination, of course. HTH, please ask questions if needed!
The dialog appears from the type detection, and the toplevel frame for the document is created later before loading the document so that's why my earlier changes didn't affect this dialog to make the new document window the parent. Though it does work for errors during the load of the document, just not for errors during the preload type detection. What we could try is a temporary unshown toplevel window to use as parent during typedection, that results in modal dialogs that are modal to a unused window so they appear visible and don't block the other visible window and the dialog parent window can listen to terminate to close itself and destroy its children automatically. https://gerrit.libreoffice.org/#/c/45044/
Caolan, thanks, I will take a look, get the patch and experiment with it...
Created attachment 137916 [details] SolarMutex added Have added the possible patch tat adds the SolarMutex. Not sure how to add this to logerrit, though. This makes the test 'CppunitTest_dbaccess_empty_stdlib_save'work. On Win, I got an error now with CppunitTest_dbaccess_nolib_save, so not sure how to proceed. I have added quite some comments to logerrit, see https://gerrit.libreoffice.org/#/c/45044/1
Crash for dbaccess_nolib_save inits from DialogSaveTest::test() line 87, xBasLib->loadLibrary(sStandard); with sStandard->"Standard". It calls SfxLibraryContainer::loadLibrary, there maNameContainer *has* no entries which leads to an exception
Strange - that last one worked now, but got a problem in CppunitTest_sw_ooxmlexport7, trying again - may be instable..?
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c46f0c9f6eb07db061d2f99c61c9ea05644a78ec Related: tdf#113160 set a temporary dialog parent during type detection It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.