1) Open an existing Base file containing data. 2) Start one of the wizards, e.g. the form wizard. A child window opens with the wizard dialog. 3) Step through the wizard until you get to the Form naming step. 4) Now close the main Base window. What actually happens : The Form child window becomes orphaned, and the wizard dialog no longer allows the user to proceed to the end of the wizard. All the user can now do is click on cancel. However, there are no messages or any other signs that he/she is now disconnected from the Base. What should happen : (a) it should not be possible to dispose of the main connection until the child has completed (b) the user should receive a warning that closing the main Base window will cause data loss (the as yet unsaved changes). Adding test ODB file. Alex
Created attachment 47840 [details] test db file
Hi Alex, I reproduce with LibO 3.4.1 on Windows 7. Bernard
Nominating as a blocker, upping criticality due to data loss. Alex
(In reply to comment #0) > 1) Open an existing Base file containing data. Hi Alex, Did you find this first on a 3.4.0 version?
Hello, The problem is still present in LO 3.4.3 Bernard
(In reply to comment #4) > Hi Alex, > Did you find this first on a 3.4.0 version? Hi Cor, Yes, but I didn't flag it as a blocker at the time because it seemed that Base bugs weren't being considered serious enough to warrant being blockers (I'm still not entirely convinced they are given due regard even today, but that is just my personal opinion). Alex
I can reproduce the pb too on 3.4.3 (pc Debian x86-32). But I don't reproduce it in master branch (future 3.5). I don't know if there has been put on 3.4 branch. I'm retrieving the 3.4 repo. Then I must compile, I should tell if I can reproduce this on 3.4.4 or 3.4.X (last sources on 3.4) by tomorrow and the next day.
I had an error compiling 3.4.4 just after having downloaded all the sources. Also, I haven't succeeded in using the pre-releases http://dev-builds.libreoffice.org/pre-releases/ Perhaps someone will more lucky than me. According to the release plan (http://wiki.documentfoundation.org/ReleasePlan), 3.4.4 will be released the 09/11.
ribotb: on which platform (x86-32, x86-64/AMD, other ?) and which environment (Windows, Linux, Mac) have you reproduced this pb ? Which version of Java do you use ? Alex: do you reproduce this on 3.4.3 ? Have you got error messages, backtrace or something ? Thanks in advance to both of you for information you could bring.
(In reply to comment #9) > > Alex: do you reproduce this on 3.4.3 ? Have you got error messages, backtrace > or something ? > > Thanks in advance to both of you for information you could bring. Hi Julien, I noticed this on Mac OSX with LO 3.4.3. Haven't tried with a 3.5 build yet. I don't recall there being a backtrace because I had to force kill the app. Alex
To Julien Nabet : platform x86 32 bits OS : Windows 7 SP1 Java : JRE 6.23
I reproduced this pb with 3.4.4.:-( (Debian SID packages of LO installed on testing Debian)
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
I can't see any NEEDINFO reason. @Lionel: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Alex: I didn't reproduce this problem on master (future 3.6) and 3.5 branch. In both case, if I click on the cross to close the main window, it does nothing, so no orphan windows. (PC Debian x86-64). Could you try again with 3.5.0 beta2 ?
This is more GUI-related than "database stuff", so I'll say "not my area" -> resetting assignee to default. I confirm that this seems fixed in 3.5. Personally, I don't see this as a very annoying bug, because the actions leading to triggering the bug are not ones the user would naturally do; they are a bit contrived. it is like in writer "I open the search/replace dialog, then close the document, the search/replace dialog does not work anymore". It is a bug, it is embarassing in that it shows "bad code/design/... quality", but not high severity overall. For all I'm concerned, we can close this as "fixed in 3.5"; if somebody wants to hunt down what fixed it in 3.5 and backport to 3.4, that's nice. I'll even review the patch if it is sent it to me.
(In reply to comment #17) Hi Lionel, > > I confirm that this seems fixed in 3.5. > > > For all I'm concerned, we can close this as "fixed in 3.5"; if somebody wants > to hunt down what fixed it in 3.5 and backport to 3.4, that's nice. I'll even > review the patch if it is sent it to me. Confirming fixed on 3.5 RC1 on Mac OSX too. Closing as resolved fixed. Alex