After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 701730 - In Brasero, Tools > Eject causes an error message
In Brasero, Tools > Eject causes an error message
Status: RESOLVED FIXED
Product: brasero
Classification: Applications
Component: general
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: Brasero maintainer(s)
Brasero maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-06-06 13:18 UTC by Marie.KOWALCZYK
Modified: 2013-07-31 12:12 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8


Attachments
Fix message error in case of eject empty drive (1.04 KB, patch)
2013-06-27 14:49 UTC, Jean-Benoit MARTIN
needs-work Details | Review
Remote the error message when cancel after eject.patch (2.20 KB, patch)
2013-07-19 06:52 UTC, hao.h.li
needs-work Details | Review
Update of Jean-Benoit MARTIN's patch to address Jonh's review and include a comment as to the root cause (1.55 KB, patch)
2013-07-19 14:41 UTC, Joshua Lock
none Details | Review
brasero-eject-dialog: don't show an error when user cancels eject (2.40 KB, patch)
2013-07-19 14:43 UTC, Joshua Lock
none Details | Review
Tweaked brasero-eject-dialog: don't show an error when user cancels eject (2.39 KB, patch)
2013-07-19 15:17 UTC, Joshua Lock
none Details | Review

Description Marie.KOWALCZYK 2013-06-06 13:18:39 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.
Comment 1 Marie.KOWALCZYK 2013-06-06 14:09:01 UTC
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.
Comment 2 Jean-Benoit MARTIN 2013-06-27 14:49:26 UTC
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)
Comment 3 Jonh Wendell 2013-07-04 14:37:59 UTC
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.
Comment 4 Joshua Lock 2013-07-18 13:37:35 UTC
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.
Comment 5 hao.h.li 2013-07-19 06:52:43 UTC
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
Comment 6 Joshua Lock 2013-07-19 14:41:13 UTC
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
Comment 7 Joshua Lock 2013-07-19 14:43:20 UTC
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.
Comment 8 Joshua Lock 2013-07-19 14:50:18 UTC
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.
Comment 9 Joshua Lock 2013-07-19 15:17:52 UTC
Created attachment 249639 [details] [review]
Tweaked brasero-eject-dialog: don't show an error when user cancels eject

Remove a potential leak
Comment 10 Joshua Lock 2013-07-30 17:43:18 UTC
I've merged the last two patches to master.
Comment 11 Jonh Wendell 2013-07-30 23:10:40 UTC
so, it's fixed then? can we close the bug?
Comment 12 Joshua Lock 2013-07-31 09:02:32 UTC
Yes, this is fixed. Unfortunately I don't (yet) have bug edit privileges - please feel free to close this.
Comment 13 Jonh Wendell 2013-07-31 12:12:24 UTC
done. btw, just ask someone in #bugs to give those permissions to you!