GNOME Bugzilla – Bug 699013
Select a file window opens up blank when opened again
Last modified: 2016-03-31 13:22:07 UTC
Created attachment 242636 [details] Screenshot When creating a box (domain) in "source selection", the "Select a file" window opens blank when reopened after canceling the previous window, disabling the user to choose any iso image. Steps to reproduce the bug 1. Click New 2. Click Continue 3. Click Select a file 4. Click Cancel 5. Click Select a file (again) The windows opens blank
Created attachment 242637 [details] Messages that appear in console after I open the window again
This is similar to bug#698828 but not the same. Most likely a gtk+ issue. If you could write a test case (a simple app that creates a gtk+ dialog in the same way as Boxes does and then launch it twice), that would be very helpful.
(In reply to comment #2) > This is similar to bug#698828 but not the same. Most likely a gtk+ issue. If > you could write a test case (a simple app that creates a gtk+ dialog in the > same way as Boxes does and then launch it twice), that would be very helpful. I guess, a test case will be apt to prove whether its a gtk+ issue or gnome-boxes one. I will look into that. By the way can you reproduce it?
(In reply to comment #3) > (In reply to comment #2) > > This is similar to bug#698828 but not the same. Most likely a gtk+ issue. If > > you could write a test case (a simple app that creates a gtk+ dialog in the > > same way as Boxes does and then launch it twice), that would be very helpful. > > I guess, a test case will be apt to prove whether its a gtk+ issue or > gnome-boxes one. Not only that but it will also make it easy for gtk+ devs (or us) to figure the cause and therefore solution. > I will look into that. Cool, thanks. > By the way can you reproduce it? Yes.
Created attachment 242686 [details] Test case The bug can not be reproduced anywhere (inside and outside jhbuild) using the test case but it can still be reproduced with boxes. Using $ jhbuild run ./test_case generates following in console $ gursimran@debian:~/gsoc/rough$ jhbuild run ./test_case Gtk-Message: Failed to load module "canberra-gtk-module" GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. The filechooser does not blanks out when opened second time. However it opens with distorted animation to confirm bug#699014 Using simply $ ./test_case generates no output on console and works fine
(In reply to comment #5) > Created an attachment (id=242686) [details] > Test case > > The bug can not be reproduced anywhere (inside and outside jhbuild) using the > test case but it can still be reproduced with boxes. > > Using > $ jhbuild run ./test_case generates following in console > > $ gursimran@debian:~/gsoc/rough$ jhbuild run ./test_case > Gtk-Message: Failed to load module "canberra-gtk-module" > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not > be saved or shared with other applications. > > The filechooser does not blanks out when opened second time. However it opens > with distorted animation to confirm bug#699014 The difference between your test app and Boxes is that former is calling 'dialog.destroy' while latter is calling 'dialog.hide'. Now we need a one-liner patch for this. :) Please do read and follow the instructions here for patch contribution: http://live.gnome.org/Git/Developers#Contributing_patches
Created attachment 242885 [details] [review] Patch for the bug Happy for my first patch to gnome-boxes
Hmm this seems to point at an issue in gtk+. I assume you checked that without the patch you get the bug, and with the patch, the bug is gone?
(In reply to comment #8) > Hmm this seems to point at an issue in gtk+. I assume you checked that without > the patch you get the bug, and with the patch, the bug is gone? The bug is not there after I changed the sourcecode. I was able to reproduce the bug before (as in the screenshot).
Good :) I'm also hitting this on my system with gtk+ master, this should also be reported against gtk+, especially if you have a small testcase for it ;)
Thanks :D I have already attached a test case, I guess it will suffice the purpose . I will report a bug there as well and point a link to this bug
What you suggest sounds good, though make sure you attach the test case to the gtk+ bug report, and add a link to that bug report here, thanks!
Did as you said, Reported GTK+ bug is bug#699376
Review of attachment 242885 [details] [review]: Since I'm hoping this is first of many commits from you, I'll be ask you to make all the changes then doing so for you while merging. :) * Short log of the commit should ideally tell about the change to the code rather than the result of it (that should be in the details). * Each line on details section should not exceed 74 characters/columns. I recently updated our wikipage about that: https://live.gnome.org/Git/CommitMessages * Once you have filed the bug on gtk+, you want to refer to that in commit log details here. You can use 'bug#NUMBER' instead of putting the complete URL to not confuse git-bz. * Keep in mind that your change is the best thing to do regardless of the gtk+ issue since the dialog is always created on the fly, the gtk+ issue only makes it mandatory. 10 bonus points for using git-bz. :) When attaching new version of this patch, do remember to use '-e' option of `git-bz attach` that makes it easy to mark previous patches obsolete.
Created attachment 243123 [details] [review] wizard-source: Fixes FileChooser which opens blank second time Changed .hide() to .destroy() which is more appropriate as dialog is always created on the fly. This also fixes the issue which has actual origin in gtk+ bug#699376. The patch fixes bgo#699013 in boxes.
Review of attachment 243123 [details] [review]: Good work. Only one nitpick: short log is still telling the result rather than what is changed. I'll merge it with micro changes. Thanks!
Review of attachment 243123 [details] [review]: Oh and it seems you didn't use git-bz for the second time although I mentioned the exact command to use. Any reason you chose to ditched git-bz?
(In reply to comment #17) > Review of attachment 243123 [details] [review]: > > Oh and it seems you didn't use git-bz for the second time although I mentioned > the exact command to use. Any reason you chose to ditched git-bz? No, I'm quite sure I used git-bz git-bz attach -e bugzilla.gnome.org:699013 HEAD
(In reply to comment #17) > Review of attachment 243123 [details] [review]: > > Oh and it seems you didn't use git-bz for the second time although I mentioned > the exact command to use. Any reason you chose to ditched git-bz? I will try to improve this next time for sure :D
(In reply to comment #19) > (In reply to comment #17) > > Review of attachment 243123 [details] [review] [details]: > > > > Oh and it seems you didn't use git-bz for the second time although I mentioned > > the exact command to use. Any reason you chose to ditched git-bz? > > I will try to improve this next time for sure :D No worries, i guess you just missed the option of obsoleting existing patch by 'uncommenting' the approp. line.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #17) > > > Review of attachment 243123 [details] [review] [details] [details]: > > > > > > Oh and it seems you didn't use git-bz for the second time although I mentioned > > > the exact command to use. Any reason you chose to ditched git-bz? > > > > I will try to improve this next time for sure :D > > No worries, i guess you just missed the option of obsoleting existing patch by > 'uncommenting' the approp. line. ya thats what i missed out.. :/