Thunderbird does not honor gnome-vfs paths

Bug #105088 reported by Wolf Rogner
234
This bug affects 41 people
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Fix Released
Wishlist
mozilla-thunderbird (Ubuntu)
Fix Released
Medium
Mozilla Bugs
Nominated for Jaunty by Param
Nominated for Karmic by Param

Bug Description

Binary package hint: mozilla-thunderbird

Try to open an attachment from a gnome-vfs path (e.g. mounted SMB network device)

Tags: quantal
Changed in mozilla-thunderbird:
importance: Undecided → Medium
Revision history for this message
John Vivirito (gnomefreak) wrote :

What version of thunderbird with what version of ubuntu. Can you please give us step by step instructions to reproduce this.

Changed in mozilla-thunderbird:
assignee: nobody → mozilla-bugs
status: Unconfirmed → Needs Info
Revision history for this message
Wolf Rogner (war-rsb) wrote :

This happens to any version of Thunderbird (1.5.0.10 and 2.0.0.4)

To verify map a SMB drive in Nautilus. Open Office can access the data on the share. Thunderbird cannot access data (like adding or saving attachments).

This is due to the fact that gnome_vfs requires a different approach to storing data on virtual drives.

By far the best solution would be to require Gnome to access virtual drives like local ones. In order to achieve this, a redirection within Gnome would be required.

Revision history for this message
Wolf Rogner (war-rsb) wrote :

It still does not work in 2.0.0.6. I have thunderbird support for gnome-vfs installed. This does not help at all.

Changed in mozilla-thunderbird:
status: Incomplete → Confirmed
Revision history for this message
Artur Flinta (aflinta-gmail) wrote :

I can confirm too, that gnome-vfs support doesn't work in thunderbird (Ubuntu gutsy, thunderbird with gnome support version 2.0.0.6 and 2.0.0.8).

Revision history for this message
papal (papal-authority) wrote :

This would be excellent to have fixed.

Revision history for this message
In , Jhorak (jhorak) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.10) Gecko/2009042708 Fedora/3.0.10-1.fc10 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.10) Gecko/2009042708 Fedora/3.0.10-1.fc10 Firefox/3.0.10

As gnomeVFS is deprecated we should port gnomevfs extension to GIO/GVFS. Gnomevfs extension allows opening sftp:// or smb:// URI directly in Firefox.

Reproducible: Always

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 378853
Initial extension patch

Use "--enable-extensions=gio" to compile with gio module.

Revision history for this message
anibal (adomail) wrote :

This bug has a few duplicates. Maybe an admin should consider consolidate all:

Bug #105088 (This one): https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bug/105088
Bug #203623: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/203623
Bug #353170: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/353170
Bug #375339: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/375339
Bug #384760: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/384760

Bug #105088 is the only one with Importance assessed: Medium. It's also the oldest: more than two years.

I can report that the same behavior of thunderbird can be observed in openSUSE 11.1. This is not an Ubuntu-only bug.

Cheers, Anibal

Revision history for this message
In , Caillon (caillon) wrote :

closing in favor of the other bug

*** This bug has been marked as a duplicate of bug 402892 ***

Revision history for this message
In , Jhorak (jhorak) wrote :

Actually this bug/patch is about GnomeVFS extension which allows to open URI like sftp:// smb://.

Bug #402892 is concerned about FF integration into Gnome (file association, MIME types, default browser settings, etc.).

Therefore the review request is still valid.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

Comment on attachment 378853
Initial extension patch

I only took a cursory look at the patch --- i.e. this is really an sr, and really not an r :-)

Revision history for this message
In , Karlt (karlt) wrote :
Download full text (6.9 KiB)

Comment on attachment 378853
Initial extension patch

>+REQUIRES = xpcom \

This can now be removed (since bug 398573).

>+# to install gnome-vfs2 in order to use the rest of mozilla ;-)

s/gnome-vfs2/gio/

>+ * This code is based on original Mozilla gnome-vfs extension. It implements
>+ * input stream provided by GVFS/GIO.

This should match the template at

http://www.mozilla.org/MPL/MPL-1.1.html#exhibit-a

so I think that means "The Original Code is the Mozilla gnome-vfs extension",
unfortunately. Although the comment is helpful, it would be better separated
from the license block.

>+ case G_IO_ERROR_FAILED: return NS_ERROR_UNEXPECTED;

Looks like G_IO_ERROR_FAILED is a generic failure, so "case
G_IO_ERROR_FAILED:" should probably just fall through to the "default:" to
return NS_ERROR_FAILURE.

>+ case G_IO_ERROR_NOT_MOUNTED:
>+ case G_IO_ERROR_HOST_NOT_FOUND: return NS_ERROR_UNKNOWN_HOST;

G_IO_ERROR_NOT_MOUNTED is here and in unhandled below. Consider
NS_ERROR_NOT_CONNECTED here, or just remove.

>+ G_IO_ERROR_INVALID_FILENAME,

NS_ERROR_FILE_INVALID_PATH

>+ G_IO_ERROR_WOULD_BLOCK,

NS_BASE_STREAM_WOULD_BLOCK

>+ G_IO_ERROR_TIMED_OUT,

Maybe NS_ERROR_NET_TIMEOUT.

>+ if (!gdk_win)
>+ return NULL;
>+
>+ // Get the container
>+ gpointer user_data = NULL;
>+ gdk_window_get_user_data(gdk_win, &user_data);
>+ if (!user_data)
>+ return NULL;

Indent the return statements, please.

>+ // Make sure its really a container
>+ MozContainer *parent_container = (MozContainer*) (user_data);
>+ if (!parent_container)
>+ return NULL;

This is barely pretending to "make sure".
It actually only needs to be a GtkWidget.
Either use GTK_IS_WIDGET or skip the check.

>+ nsCOMPtr<nsIBaseWindow> baseWin(do_QueryInterface(reinterpret_cast<nsISupports*> (window->GetDocShell()) ));

>+ baseWin = do_QueryInterface(reinterpret_cast<nsISupports*> (window->GetDocShell()) );

The reinterpret_casts don't look right.
Does including nsIDocShell should fix the problem?

>+ nsCOMPtr<nsIWindowWatcher> wwatch =
>+ do_GetService(NS_WINDOWWATCHER_CONTRACTID, &rv);
>+ //NS_ENSURE_SUCCESS(rv, rv);

Should check for failure here somehow.

>+
>+ nsCOMPtr<nsIDOMWindow> active;
>+ wwatch->GetActiveWindow(getter_AddRefs(active));
>+
>+ GtkWindow *parent_wnd = NULL;
>+ parent_wnd = get_gtk_window_for_nsiwidget(DOMWindowToWidget(active));

This doesn't look thread-safe.

And is there always an active window?

We actually have no idea which window is associated with the stream (AFAIK).
Is the transient parent important?

>+ GMountOperation* mount_op = gtk_mount_operation_new(parent_wnd);

gtk_mount_operation_new needs gtk+-2.14 so there needs to be a configure check
for that version.

Is GTK thread-safe?

>+ if (error) {
>+ g_warning("Error reading directory content: %s", error->message);
>+ nsresult rv = MapGIOResult(error);
>+ g_error_free(error);
>+ return rv;
>+ }
>+ g_object_unref(f_enum);

f_enum needs to be freed even if error.

>+ if (mime_type && strcmp(mime_type, APPLICATION_OCTET_STREAM) != 0) {
>+ SetContentTypeOfChannel(mime_type);
>+ g_free(mime_type);
>+ }

m...

Read more...

Revision history for this message
Kieran Fleming (kieran-fleming) wrote :

In Thunderbird 2.0.0.23, I can attach and send files from network locations. However, bookmarks and places that go to network locations are not shown in the file picker. The only way I can get it to work is if the file I want is in the 'Recent Documents' entry.

Revision history for this message
Michael B. (berenshteyn) wrote :

try this go to: /home/username/.gvfs

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 401429
Patch 0.2, fixed according to review comments

Thanks a lot for your comments. I've tried to fix problematic issues. I've also dropped from searching for root window (to be able to create modal dialogue).

In fact while invoking command 'firefox sftp://etc' failed to get root window anyway. The problem is that if you close the Firefox while the login window is still showed the Firefox keeps naturally running. Right now I'm not sure how to solve this issue.

Could you look at this patch once again, please?

Also please look at GTK 2.14 checking in configure.in, I'm not very sure if this is the right way to do the version checking.

Revision history for this message
In , Karlt (karlt) wrote :

(In reply to comment #6)
> The problem is that if you close the Firefox while the login window is
> still showed the Firefox keeps naturally running. Right now I'm not sure how to
> solve this issue.

What did the gnomevfs extension do here?

nsAppStartup counts XUL windows and tries to quit when the last is closed;
that may cause some problems here.

Would it make sense to implement a GMountOperation (to replace the GtkMountOperation) using nsIAuthPrompt (like the gnomevfs extension used)?

One thing we need to tell the user when asking for a password is the host to which they are connecting.

Revision history for this message
Param (parameswarand) wrote :

this is not at all a solution. It is difficult to type all those locations

Revision history for this message
ghostwriter78 (ghostwriter78) wrote :

Non-expert users have great difficulties with that.

I often select a file on a SMB windows share and drag it into thunderbird, it shows the SMB path but it cant send the file.
On Evolution Mail client that works perfectly!

can somebody check whats the issue and how to solve it?

regards
tibor

Revision history for this message
In , Reed Loden (reed) wrote :

Jan, any updates on this?

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 421233
Patch 0.3, switched from gtk_mount_operation back to nsIAuthPrompt

Sorry for long delay. I've removed gtk_mount_operation and put nsIAuthPrompt back. I also switched to using observers for getting dialogue result.
Any ideas for?:
  while (!mMountFinished) {
    PR_Sleep(1000); // XXX waiting loop
  }
Please could you check it?

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 421249
Patch 0.3b, switched from gtk_mount_operation back to nsIAuthPrompt

Sorry, bogus diff parts.

Revision history for this message
In , Sgautherie-bz (sgautherie-bz) wrote :

Comment on attachment 421249
Patch 0.3b, switched from gtk_mount_operation back to nsIAuthPrompt

>diff -r 1a3d81ba980a config/autoconf.mk.in
>@@ -261,16 +261,19 @@ MOZ_GCONF_CFLAGS = @MOZ_GCONF_CFLAGS@
> MOZ_GIO_CFLAGS = @MOZ_GIO_CFLAGS@
> MOZ_GIO_LIBS = @MOZ_GIO_LIBS@
>
>+MOZ_GIO_CFLAGS = @MOZ_GIO_CFLAGS@
>+MOZ_GIO_LIBS = @MOZ_GIO_LIBS@
>+

Bad merge?

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 426480
Patch 0.4, removed configure.in and autoconf.mk.in diffs.

Sorry, you're right. Removed diffs of configure.in and autoconf.mk.in as they are obsolete now.

Revision history for this message
Christian (kingkiki) wrote :

any solution to this?

Revision history for this message
In , Karlt (karlt) wrote :
Download full text (7.1 KiB)

Comment on attachment 426480
Patch 0.4, removed configure.in and autoconf.mk.in diffs.

(In reply to comment #9)
> I also switched to using observers for getting dialogue result.

These observers are retrieving the result of g_file_mount_enclosing_volume
(rather than the password dialog). nsIObserverService is really for global
notifications. Here IIUC there could be multiple concurrent nsGIOInputStreams
and thus multiple GMountOperations. It seems that
mount_enclosing_volume_finished needs a reference to the nsGIOInputStream.

> Any ideas for?:
> while (!mMountFinished) {
> PR_Sleep(1000); // XXX waiting loop
> }
> Please could you check it?

mozilla::Monitor should suit this case:

http://hg.mozilla.org/mozilla-central/annotate/f7a9b2f21b09/xpcom/glue/Monitor.h#l59
https://developer.mozilla.org/en/NSPR_API_Reference/Introduction_to_NSPR#NSPR_Thread_Synchronization

It would be helpful to have some comments explaining on which thread the
callbacks from g_file_mount_enclosing_volume will be invoked.
(It's a little counter-intuitive that its neither the thread that called
g_file_mount_enclosing_volume nor the thread that created the GMountOperation.

I don't know that we can be sure that nsGIOInputStream::Read is always called
off the main thread. If it gets called on the main thread, MountVolume will
lock. I think the right thing to do if G_IO_ERROR_NOT_MOUNTED is received
when called on the main thread is just skip the MountVolume and return an
error. It looks like "bool NS_IsMainThread()" is the function to use to check
this.

Can you check the list of headers included please?
There have been some modifications so I think some are longer be needed.

configure.in should probably have a check that gio is available, similar to
the `echo "$MOZ_EXTENSIONS" | grep -c gnomevfs` test.

>+ * The Original Code is IBM Corporation.

"* The Original Code is the Mozilla gnome-vfs extension.
 *
 * The Initial Developer of the Original Code is IBM Corporation."

>+ case G_IO_ERROR_NOT_MOUNTED: return NS_ERROR_NOT_CONNECTED

>+/* unhandled:
>+ G_IO_ERROR_NOT_REGULAR_FILE,
>+ G_IO_ERROR_NOT_SYMBOLIC_LINK,
>+ G_IO_ERROR_NOT_MOUNTABLE_FILE,
>+ G_IO_ERROR_TOO_MANY_LINKS,
>+ G_IO_ERROR_NOT_MOUNTED,

G_IO_ERROR_NOT_MOUNTED is handled above so remove it from this list.

>+ // Make sure authIn->uri is consistent with the channel's URI.
>+ //
>+ // XXX This check is probably not IDN safe, and it might incorrectly
>+ // fire as a result of escaping differences. It's unclear what
>+ // kind of transforms GnomeVFS might have applied to the URI spec
>+ // that we originally gave to it. In spite of the likelihood of
>+ // false hits, this check is probably still valuable.
>+ //
>+ nsCAutoString spec;
>+ uri->GetSpec(spec);
>+ int uriLen = strlen(default_domain);
>+ if (!StringHead(spec, uriLen).Equals(nsDependentCString(default_domain, uriLen)))
>+ {
>+ LOG(("gnomevfs: [spec=%s authIn->uri=%s]\n", spec.get(), default_domain));
>+ NS_ERROR("URI mismatch");
>+ }

I wouldn't expect default_domain to be the same as the spec. It seems the
only reason this passes (when...

Read more...

Revision history for this message
In , Karlt (karlt) wrote :

(In reply to comment #13)
> It looks like the channel could be destroyed before
> mount_operation_ask_password is called.

Sorry, I think I'm wrong here and I expect what you have is fine.
I don't completely grasp the relationship between the nsGIOInputStream and the nsIChannel, but I assume that, if a thread is Read()ing the nsGIOInputStream, something must be holding a reference to the nsIChannel.

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 445660
Patch 0.5, Monitor added, observers removed

Removed observers replacing them with user pointer in mount_enclosing_volume_finished. Added comments about threads, Waiting loop replaced by monitor.

Usage of Cancel method for channels shows nice error messages to user which depends on gio failure type. Please have a look.

Revision history for this message
In , Karlt (karlt) wrote :

Comment on attachment 445660
Patch 0.5, Monitor added, observers removed

>+ else
>+ if test `echo "$MOZ_EXTENSIONS" | grep -c gio` -ne 0; then
>+ PKG_CHECK_MODULES(MOZ_GNOMEVFS, gio-2.0 >= $GIO_VERSION [
>+ MOZ_GIO_LIBS=`echo $MOZ_GIO_LIBS | sed 's/-llinc\>//'`
>+ ])
>+ fi

This would need a comma after GIO_VERSION, I assume, and the first argument
would need to be MOZ_GIO, but this doesn't work anyway because MOZ_EXTENSIONS
is not yet set.

That means that the same test for MOZ_GNOMEVFS doesn't work either and so
I guess no one has used that.

Therefore feel free to just leave configure.in as is and --enable-gio will be needed to build the gio extension.

>+LOCAL_INCLUDES = $(MOZ_GTK2_CFLAGS) \
>+ $(MOZ_GIO_CFLAGS)
>+

>+EXTRA_DSO_LDOPTS = \
>+ $(XPCOM_GLUE_LDOPTS) \
>+ $(NSPR_LIBS) \
>+ $(MOZ_GTK2_LIBS) \
>+ $(MOZ_GIO_LIBS) \
>+ $(NULL)

>+#include <gtk/gtk.h>

GTK is no longer used. I expect gio/gio.h would be sufficient.

>+ mozilla::MonitorAutoEnter mon(mMonitorMountInProgress);
>+ /* Waiting for finish of mount operation thread */
>+ mon.Wait();
>+ g_warning("monitor done");
 + g_object_unref(mount_op);

The state of the mount operation should be checked before waiting in case the
operation already Notify/signals before this wait starts. Also
pthread_cond_wait() can wakeup spuriously, so the state should be checked on
return from Wait(). If G_MOUNT_OPERATION_IN_PROGRESS were a
GMountOperationResult this would normally look something like

   while (mMountRes == G_MOUNT_OPERATION_IN_PROGRESS)
     mon.Wait();

>+ * nsGIOInputStream. This function is called in main thread as async request
>+ * from dbus.

How about "main thread as an async request typically from dbus"?
IIUC, while gvfs is implemented using dbus, GIO need not necessarily use dbus, for other modules for example.

If G_ASK_PASSWORD_NEED_DOMAIN is requested, should the reply be
G_MOUNT_OPERATION_UNHANDLED?

Please remove the debugging g_warnings.
Ideally g_warnings would only be for cases where the code is misused
(and normally we use NS_ASSERTION for that).

Revision history for this message
In , Karlt (karlt) wrote :

(In reply to comment #15)
> Usage of Cancel method for channels shows nice error messages to user which
> depends on gio failure type. Please have a look.

How do you get these error messages and where do you see them?
I tried sftp://notauser@localhost/etc, cancelling and entering the wrong
password 3 times.

And how do you know that it is safe to call nsIInputStreamChannel::Cancel()
from the Read() thread?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

> And how do you know that it is safe to call nsIInputStreamChannel::Cancel()
> from the Read() thread?

It's not, unless the Read() thread is the main thread.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

I'd think an error rv from Read() would propagate into the channel status. Does it not?

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 446488
Patch 0.6, warnings removed, Cancel removed

Sorry for confusion with Cancel. Error reporting works without calling it. Sorry also for g_warning leftovers (they was just for my debug runs).

I removed Cancel call, useless g_warnings and configure.in changes.

There is still no feedback when user aborts password dialog or fill wrong login/pass.

Revision history for this message
In , Karlt (karlt) wrote :

Comment on attachment 446488
Patch 0.6, warnings removed, Cancel removed

Thank you, Jan. This is looking good.

(In reply to comment #20)
> There is still no feedback when user aborts password dialog or fill wrong
> login/pass.

I don't think we need to sort that out in order to land this. The gnomevfs extension seems to leave no feedback on failure often enough.

>+ /* Calling g_file_mount_enclosing_volume creates a new thread */

Is this actually true? I thought typically it would start a new process and
send a dbus request. But really it could do anything. The key is that it is
asynchronous and the reply arrives on the main thread.

>+ /* Waiting for finish of mount operation thread */
>+ while (mMountRes == G_MOUNT_OPERATION_UNHANDLED)

I was initially worried that this might sometimes get set to
G_MOUNT_OPERATION_UNHANDLED as a GIO result of
g_file_mount_enclosing_volume().
But then I remembered that mMountRes is only set to internal values based on
the error from g_file_mount_enclosing_volume_finish.

I think it would be clearer to use an internal enum type for mMountRes with 3 values for the in-progress/failure/success states.

Revision history for this message
haydemon (haydemon-gmail) wrote :

This seems to be a recurring problem with everyone. I've searched forums, blogs, posts, etc., and nothing. Although not critical, it's just inefficient having to make duplicate file copies and saving them to the desktop for the sole purpose of attaching to emails. Who do we have to kill to elevate this in the food chain of annoyances to be fixed?

Revision history for this message
Bill Turner, wb4alm (wb4alm) wrote :

it is more than "inefficient" when you have a number of emails that need multiple attachments, especially when all individuals get a unique attachment and everybody gets a copy of a set of "standard" attachments. Having to copy the files to the desktop, rather than using SMB patch to the remote system(s) just complicates everything.

I don't have the necessary expertise to provide a fix for this - but I m having difficultly understanding why this is so hard to fix it.... Most applications that I deal with seem to have no problem utilizing standard system resources, regardless of the Linux distribution or the exact desktop (Gnome/KDE)....

Revision history for this message
neuromancer (neuromancer) wrote :

Just a workaround for now.
Create a symlink from mounted network share (samba or other) to a local folder
e.g. sudo ln -s /home/username/.gvfs/srv_folder\ su\ 172.16.0.1/ /media/srv1
Now create a bookmark to /media/srv1

Accessing this bookmarked folder with thunderbird work greatly: all file are attached correctly.

Note: if you unmount network share, symlink is broken, so folder is not accesible. When you boot machine is necessary to mount all your desidered network share.

Revision history for this message
pramathesh ambasta (pramathesh-ambasta) wrote : Re: [Bug 105088] Re: Thunderbird does not honor gnome-vfs paths

On 07/21/10 15:52, neuromancer wrote:
> Just a workaround for now.
> Create a symlink from mounted network share (samba or other) to a local folder
> e.g. sudo ln -s /home/username/.gvfs/srv_folder\ su\ 172.16.0.1/ /media/srv1
> Now create a bookmark to /media/srv1
>
> Accessing this bookmarked folder with thunderbird work greatly: all file
> are attached correctly.
>
> Note: if you unmount network share, symlink is broken, so folder is not
> accesible. When you boot machine is necessary to mount all your
> desidered network share.
>
>

I know about the workaround and I have been following something similar
to work with Thunderbird. But when Thunderbird claims to be integrated
with gnome, I don't see why anyone should need to do this. Think about
an ordinary user wanting to use Ubuntu/Thunderbird. It will be very
discouraging to have to get into symlinks etc.

Pramathesh

Revision history for this message
Erik Meitner (e.meitner) wrote :

This bug ought to be linked with this one (same issue affecting Firefox): bug #31471.

Revision history for this message
cne007 (lepelerin2002) wrote :

Still an issue. I am using TB 3.0.10, Ubuntu 10.04.1 LTS.
This is simply very strange to have such a basic functionality unsolved for a couple 3.5 years.
I use the workaround of symlink, however this is not something that should be asked to the end user!
Very frustrating when you try to promote Linux and open source software. The M$ users have a point there. Sorry.

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 501303
Patch 0.7, sync to mozilla-central

Please have a look at version synced with latest mozilla-central. When review gets positive I'll try to set need-checkin.

Revision history for this message
In , Karlt (karlt) wrote :

The merge with m-c looks good, thanks, but, before checkin, can you correct the "Calling g_file_mount_enclosing_volume creates a new thread" comment and use a new distinct enum type for mMountRes, in line with comment 21, please?

We'll also need to get approval2.0, but as this is not part of the default build, I don't expect that to be a problem.

Revision history for this message
In , Karlt (karlt) wrote :

Comment on attachment 501303
Patch 0.7, sync to mozilla-central

>+#include "nsIStandardURL.h"
>+#include "nsMimeTypes.h"
>+#include "nsNetUtil.h"
>+#include "mozilla/Monitor.h"
>+#include "nsIStandardURL.h"

One of the nsIStandardURL.h includes can be removed too :)

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 501632
Patch 0.8, fixed comments and added mount operation enum

Here it comes...

Revision history for this message
In , Karlt (karlt) wrote :

Comment on attachment 501632
Patch 0.8, fixed comments and added mount operation enum

>+nsGIOInputStream::SetMountResult(GMountOperationResult result, gint error_code)
>+{
>+ mozilla::MonitorAutoEnter mon(mMonitorMountInProgress);
>+ mMountRes = (result == G_MOUNT_OPERATION_HANDLED)
>+ ? MOUNT_OPERATION_SUCCESS : MOUNT_OPERATION_FAILED;

SetMountResult is only used in this file and the parameter is not really a
GMountOperationResult. It should be the internal enum "MountOperationResult".

>+ , mMountRes(MOUNT_OPERATION_IN_PROGRESS)

mMountRes is only used in nsGIOInputStream::MountVolume() so doesn't need to
be initialized here.

>+ /* A g_file_mount_enclosing_volume is using dbus request to mount volume.

"/* g_file_mount_enclosing_volume uses a dbus request to mount the volume."

>+ Callback mount_enclosing_volume_finished is called in main thread
>+ (not this thread from witch it this method called). */

"(not this thread on which this method is called)."

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 502458
Patch 0.9, fixed comments and mount operation enum

Ah, sorry about it, I was too hasty with enums. Thanks for fixing comments too.

Revision history for this message
In , Karlt (karlt) wrote :

Comment on attachment 502458
Patch 0.9, fixed comments and mount operation enum

>+++ b/extensions/gio/Makefile.in Mon Jan 10 12:32:39 2011 +0100
>+# This code is based on original Mozilla gnome-vfs extension. It implements
>+# input stream provided by GVFS/GIO.

This license header needs to be made consistent with the original gnomevfs
Makefile.in, in the same way as you fixed up for nsGIOProtocolHandler.cpp.

I think we can request approval2.0 when that's done.

Revision history for this message
In , Jhorak (jhorak) wrote :

Created attachment 502759
Patch 0.1, fixed license

Revision history for this message
In , Karlt (karlt) wrote :

(In reply to comment #23)
> ... this is not part of the default build ...

To be more precise:
This extension is not enabled by default. The only change to the default build here is a lookup of the service NS_NETWORK_PROTOCOL_CONTRACTID_PREFIX"moz-gio" (which won't normally be present). This is similar to what is done for the gnomevfs extension.

The benefit of the patch is that distributions no longer shipping gnomevfs can enable the gio extension for similar behaviour using modern system libraries.

Revision history for this message
In , Jhorak (jhorak) wrote :

Setting checkin-needed, is it possible?

Revision history for this message
In , Mounir (mounir) wrote :

(In reply to comment #31)
> Setting checkin-needed, is it possible?

Unfortunately not. This patch need to be approved before landing on mozilla-central because we are too close to the release. If it's not approved, it will be able to be pushed after the release.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

I really think we should take this post-FF4.

Revision history for this message
In , Jst (jst) wrote :

Comment on attachment 502759
Patch 0.1, fixed license

Agreed, this is too big of a change for Firefox 4 at this point. We'll get this in after branching!

Revision history for this message
In , Ehsan-mozilla (ehsan-mozilla) wrote :
Revision history for this message
In , Ehsan-mozilla (ehsan-mozilla) wrote :
Revision history for this message
In , Chpe (chpe) wrote :

The patch as checked in still is full of debugging g_warnings()s; I think they should be removed, as the reviewer in comment 5 and comment 16 also said.

MapGIOResult(gint) converts GIOErrorEnum codes to nsresult, but MapGIOResult(GError*) hands it any GError's ->code without first checking that ->domain == G_IO_ERROR (there's no guarantee all those gio functions only return G_IO_ERROR errors).

Revision history for this message
alienn (spamme-ubuntu) wrote :

Just tried it with Ubuntu Maverick and Thunderbird 3.1.8 with the package /thunderbird-gnome-support_3.1.8+build3+nobinonly-0ubuntu0.10.10.1_amd64.deb installed and it still does not work.

Just as a side note. This was one of the major blocking bugs which prevented ubuntu from beind installed in a company. A workaround was not an option...

Revision history for this message
Erik Meitner (e.meitner) wrote :

For the 40+ Ubuntu workstations at my employer I have a workaround:
In Nautilus create a bookmark that points to the ".gvfs" folder. I named it "Shares/Devices". People can then click this bookmark to see all the GVFS mounted shares and devices. I then had to train our users in this inconsistency.

Revision history for this message
thenamelessthing (pgagne) wrote :

Please fix this bug! It will be more efficient for every thunderbird user on Linux.

Revision history for this message
BenE (b-eckl) wrote :

Yea, seriously, please fix this bug. It is unbelievable, that thunderbird this widespread all over the world is not able to serve with this tiny feature.
Thanks for your work guys!

Revision history for this message
Erik Meitner (e.meitner) wrote :

There seems to have been some progress by the upstream developers. This bug filed against Core/Networking indicates that the fix has been released:
https://bugzilla.mozilla.org/show_bug.cgi?id=494163

Note that the above bug references this Ubuntu bug for the same problem in Firefox:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/539226

That report states that "Starting with Ubuntu 11.04, Firefox is compiled with gio. "

Changed in thunderbird:
importance: Unknown → Wishlist
status: Unknown → Fix Released
Franck (alci)
tags: added: quantal
Revision history for this message
Franck (alci) wrote :

This problem still shows in Quantal beta in Thunderbird...

Revision history for this message
Franck (alci) wrote :

Here is a workaround for the problem, taking the problem at a lower level (and suitable for business environment):

1) install autofs ('sudo apt-get install autofs')
2) also install any tools needed to access your network resources (for example) cifs-utils
3) configure autofs (see for example http://www.lamolabs.org/blog/6000/one-liner-mounting-a-smbcifs-share-as-an-automount-on-centosfedorarhel/ )

Then your resource is managed at a low level (kernel / daemon) and the apps don't need to be aware of it. This will solve the problem for Thunderbird as well as for any other app that is currently unaware of GIO (for example Freemind, GanttProject, ...)

Revision history for this message
Andreas Heinlein (aheinlein) wrote :

This workaround only works if you have static (i.e. previously known) network resources you want to connect to. In our case, we have ad-hoc shares of e.g. USB thumb drives which need to be accessed over the network. That's just the point of user-level managed network resources, I think.

Revision history for this message
Franck (alci) wrote :

@Andreas: I agree with you, this is _only_ a workaround, and this bug should be fixed. Moreover, Thunderbird seems to be compiled with --enable-gio option, so I was under the impression it should already work...

That said, regarding autofs, have you looked at autofs wildcards ? I far from being an expert, but this might work...

Revision history for this message
Phoenix (phoenix-dominion) wrote :

I have Tthunderbird 17. Ubuntu 12.10

It is FRIGGING 6 YEARS OLD THAT THUNDERBIRD CANT ACCESS NETWORK FILES!!!!
(no fstab does not count as a solution, and walking though .gnomefs neither - if it doesn't dupport drag and drop from nautilus and can be access like a user is used to access his network share than it is not a considerbale solution. It is like saying to people: hey, you door doesn't work, use the window....)

To be honest: I have to laugh, otherwise I would cry HOW SOMETHING SO FUNDAMENTAL IS MISSING.
IT IS LIKE A TYPEWRITER SOFTWARE IS MISSING PRINTING FUNCTIONALITY

Insane... simply insane... MY ANDROID PHONE HAS BETTER APPS THAN MY DESKTOP OS... that is so silly

I wish I had Android on my Desktop.... fully integrated and not a bunch of patches and workarounds.

Revision history for this message
Philipp Gassmann (phiphi.g) wrote :

Workaround:
It works when you access the mounts via ~/.gvfs/smb\ on\ ...

or you can link the hidden virtual folder to a no-hidden name: ln -s ~/.gvfs ~/network

Revision history for this message
Rubeosis (faspie) wrote :

I can confirm this bug for raring.

Revision history for this message
new4u (new4u) wrote :

I also miss this feature to be honest, and I am surprised about its missing...

Revision history for this message
Oliver Sauder (sao) wrote :

I have checked this again on Ubuntu 13.10 with Thunderbird 1:24.4.0+build1-0ubuntu0 and seems to work as long as the network share is connected through Nautilus already.

When I then go to attach I can choose the already connected network share in the left Places panel.

What does not work is when a network share is not connected already it will simply not appear in the dialog and cannot be chosen.

Revision history for this message
Wolf Rogner (war-rsb) wrote :

Oliver,

I can confirm this behaviour. In fact, this is sufficient.
I don't believe there should be a way in thunderbird to mount volumes. This is the responsibility of other applications.

I'm happy
Issue can be closed.

Thanks

Oliver Sauder (sao)
Changed in mozilla-thunderbird (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Andreas Heinlein (aheinlein) wrote :

Don't know if thats version specific, but it does not work with thunderbird 1:24.4.0+build1-0ubuntu0.12.04.1 on precise.

Revision history for this message
.cobnet (mattias-campe) wrote :

I'm using Ubuntu 14.04 with Thunderbird 31 and I can partially confirm this bug.

What is working:
-) Mount an samba-share with Nautilus
-) Compose a message in Thunderbird and CLICK ON THE ATTACHMENT BUTTON
-) The samba share should be visible on the left (but it might be in a different order compared to Nautilus as there is no seperate "Network"-item.
-) Browse to the files you want to add.

What is not working:
-) Mount an samba-share with Nautilus.
-) Compuse a message in Thunderbird and DRAG AND DROP A FILE from the mounted Samba-share in Nautilus into the compose windows
-) A link smb://name of sambaserver/path to file appears in the message in Thunderbird, but Thunderbird is unable to send the file.

I don't know if this is a bug in Thunderbird or Nautilus, but I don't think this issue can be closed.

Somebody refers to "~/.gvfs/smb\" but I think the mounting changed since that comment. Now it can be find in /run/user/uid/gvfs/smb-share:server=X,share=Y, where uid can be 1000 and X and Y have other values.

Revision history for this message
In , Ben-bucksch (ben-bucksch) wrote :

xref bug 1058177 - gvfs within firefox process using 100% disk.

Revision history for this message
Doudz (sebastien-ramage) wrote :

I confirm that DRAG AND DROP A FILE from the mounted Samba-share in Nautilus into the compose windows doesn't work in vivid, Ubuntu 15.04.

Thunderbird said :
L'envoi du message a échoué.
Une erreur est survenue en joignant smb://servername/share/doc.pdf. Veuillez vérifier que vous avez accès au fichier.

Revision history for this message
EAB (adair-boder) wrote :

Ubuntu 14.04.3 - Thunderbird 38.3.0
Samba shares are mounted and accessible via Files file manager.
Drag-n-Drop file from mounted Samba share into new Email attachments area works.
Cannot send email due to:

"Sending of the message failed.
There was an error attaching smb://server/path/to/file. Please check that you have access to the file."

Totally embarrassing to have to tell Linux users that this simple feature is not working ... complete let-down!!

Revision history for this message
EAB (adair-boder) wrote :

I opened a new bug report since this one seems to be being ignored > https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bug/1515288

Revision history for this message
Wolf Rogner (war-rsb) wrote :

Thunderbird 38.3 does not show this any more.

Revision history for this message
EAB (adair-boder) wrote :

I have TB 38.3.0 and it's still a problem - as I mentioned above (#75)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.