GNOME Bugzilla – Bug 701730
In Brasero, Tools > Eject causes an error message
Last modified: 2013-07-31 12:12:24 UTC
Steps: 1. Go to Brasero. (Don't insert CD) 2. Select Tools> Eject. Expected outcome: CD does get ejected Actual outcome: Brasero closes and "An unknown error has occurred." message pops up.
I add some informations about this bug: Steps: 1. Go to Brasero. 2. Select Tools> Eject. 3. Click "Eject" button 4. the disk id ejected. 5. click on "Cancel" Expected outcome: the windows closes Actual outcome: Brasero closes and "An unknown error has occurred." message pops up.
Created attachment 247912 [details] [review] Fix message error in case of eject empty drive The patch checks if no media is present in the drive in case of eject. PS: The file libbrasero-media/brasero-gio-operation.c has windows meta-character (^M)
Review of attachment 247912 [details] [review]: I'm not commenting on the root cause of this, just in the patch itself. I don't know if this is the right approach... ::: libbrasero-media/brasero-gio-operation.c @@ +383,3 @@ brasero_gio_operation_end (operation); + else if (!g_drive_has_media (G_DRIVE (source))) + brasero_gio_operation_end (operation); you're assuming the 'source' variable is a GDrive object, which is not always true.
The root of this seems to be that before the drive is ejected with wait = TRUE we connect the brasero_gio_operation_ejected_cb () callback to the GDrive::changed signal. When the drive has a disc in the ::changed signal is emitted and brasero_gio_operation_ejected_cb () calls brasero_gio_operation_end (), however when there's no disc in the optical drive the ::changed signal is not emitted when the drive is ejected. I'm not sure if it's a bug in GIO or not that an empty optical drive doesn't emit a ::changed signal when it's ejected (the documentation doesn't indicate strongly either way), however I believe that's how we end up hitting the brasero_gio_operation_timeout () callback due to brasero_gio_operation_end () not having been called.
Created attachment 249580 [details] [review] Remote the error message when cancel after eject.patch I tried the patch, it can fix the issue when there is no CD inserted. But when there is CD inserted, when I click eject and then click Cancel quickly, it will also report the "An unknown error has occurred." I suggest when eject button is pressed and then cancel button is pressed, no matter if the cancel can be done or not, it doesn't have to show the message "An unknown error has occurred." when there is no specific error for avoid confusing error message
Created attachment 249636 [details] [review] Update of Jean-Benoit MARTIN's patch to address Jonh's review and include a comment as to the root cause
Created attachment 249637 [details] [review] brasero-eject-dialog: don't show an error when user cancels eject (In reply to comment #5) > But when there is CD inserted, when I click eject and then click Cancel > quickly, it will also report the "An unknown error has occurred." > > I suggest when eject button is pressed and then cancel button is pressed, no > matter if the cancel can be done or not, it doesn't have to show the message > "An unknown error has occurred." when there is no specific error for avoid > confusing error message I observed the same thing but actually worked out a different patch (before I saw yours) which doesn't show an error dialog in the situation where the user clicks Cancel and no error was reported.
Review of attachment 249580 [details] [review]: ::: src/brasero-eject-dialog.c @@ +106,3 @@ + else + { + if (error) This isn't quite right, if error is non NULL you should handle it and report the cause to the user, when error is NULL would be more appropriate to show a specific error message. Conversely I'm not certain (haven't verified) that error is only NULL when the user cancels the operation.
Created attachment 249639 [details] [review] Tweaked brasero-eject-dialog: don't show an error when user cancels eject Remove a potential leak
I've merged the last two patches to master.
so, it's fixed then? can we close the bug?
Yes, this is fixed. Unfortunately I don't (yet) have bug edit privileges - please feel free to close this.
done. btw, just ask someone in #bugs to give those permissions to you!