Closed Bug 255900 Opened 20 years ago Closed 20 years ago

Attaching an attachment is not possible on the gtk2 version

Categories

(MailNews Core :: Attachments, defect)

x86
Linux
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: svdmade, Assigned: caillon)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

Steps to reproduce

1 open a new email
2 open the attachment window
3 try to add an attachment. I'm trying a simple text attachment of <2KB
4 the attachment won't be sent or shown in the attachment window

I'm using the nightly build of mozilla-i686-pc-linux-gnu-gtk2+xft.tar.gz dated
17aug2004
Reporter, in your navigator File menu, select "Open File", does mozilla crash?
No mozilla doesn't crash when I

1 Click on file
2 Click on Open file CTRL - O
3 and open an xml file in the navigator window
Building myself, I am also seeing this. It seems related to the usage of the new
file selector. I didn't see this with an older GTK2 build which used the old
file selector. The new one generally works (e.g. folder selection for saving
attachments) and does not lead to a crash, as reported. Also, I don't get any
output in the Javascript Console.

Quite severe, I think. Requesting blocking 1.8a4.
Flags: blocking1.8a4?
(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040819)

Also experiencing the same behaviour on the 1.8a3 gtk2+xft build available at
http://www.scottbolander.com/mozilla-1.8a3-xft-gtk2-pc-linux-gnu.tar.bz2

Is there any workaround known?
Flags: blocking1.8a4? → blocking1.8a4+
I see the following output on the console with a Gtk2 debug build when I try to
attach a file:

(Gecko:11909): GLib-GObject-WARNING **: invalid cast from `GdkWindow' to `GtkWindow'

(Gecko:11909): Gtk-CRITICAL **: file gtksettings.c: line 447
(gtk_settings_get_for_screen): assertion `GDK_IS_SCREEN (screen)' failed

(Gecko:11909): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(Gecko:11909): GLib-GObject-CRITICAL **: file gsignal.c: line 1726
(g_signal_handler_disconnect): assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(Gecko:11909): Gtk-CRITICAL **: file gtkwindow.c: line 1883
(gtk_window_set_transient_for): assertion `parent == NULL || GTK_IS_WINDOW
(parent)' failed


After the first output

(Gecko:11909): GLib-GObject-WARNING **: invalid cast from `GdkWindow' to `GtkWindow'

Mozilla hangs for some minutes. After this the file picker dialog opens. The
file picked there isn't added to the attachment list.

nuno.ponte: Only drivers are allowed to set blocking-flags to + or -. Everyone
else only have the permission to request a blocking status via ?.
Severity: normal → major
Flags: blocking1.8a4+ → blocking1.8a4?
Keywords: regression
*** Bug 257225 has been marked as a duplicate of this bug. ***
I'm seesing similar output as in comment 5.

bash-2.05b$ ./mozilla

(Gecko:290): GLib-GObject-WARNING **: invalid cast from `GdkWindow' to `GtkWindow'

(Gecko:290): Gtk-CRITICAL **: file gtkwindow.c: line 1941
(gtk_window_set_transient_for__internal_alias): assertion `parent == NULL ||
GTK_IS_WINDOW (parent)' failed

(Gecko:290): GLib-GObject-WARNING **: invalid cast from `GdkWindow' to `GtkWindow'

(Gecko:290): Gtk-CRITICAL **: file gtkwindow.c: line 1941
(gtk_window_set_transient_for__internal_alias): assertion `parent == NULL ||
GTK_IS_WINDOW (parent)' failed

(Gecko:290): GLib-GObject-WARNING **: invalid cast from `GdkWindow' to `GtkWindow'

(Gecko:290): Gtk-CRITICAL **: file gtkwindow.c: line 1941
(gtk_window_set_transient_for__internal_alias): assertion `parent == NULL ||
GTK_IS_WINDOW (parent)' failed

(Gecko:290): GLib-GObject-WARNING **: invalid cast from `GdkWindow' to `GtkWindow'

(Gecko:290): Gtk-CRITICAL **: file gtkwindow.c: line 1941
(gtk_window_set_transient_for__internal_alias): assertion `parent == NULL ||
GTK_IS_WINDOW (parent)' failed
sending back success status; version 5
I guess Gtk2 builds aren't "smoketest" stuff, but this sure is a blocker.
Changing severity.
Severity: major → blocker
Also: Mozilla now crash if i open mail, try to attach a file, close attachment
pane, and then mount a CD or DVD.
Caillon: Filepicker in Mailnews is still broken on gtk2 builds. 
Seems the checkin for bug 123197 caused that.
Will fixing bug 253136 make mailnews usable again?
I hope so, cause this bug is really painful.
This seems to be largely similar to bug 255366 which on amd64 is a crasher.
*** Bug 258347 has been marked as a duplicate of this bug. ***
Blocks: gtk2
Chris Aillon asked that this bug get re-assigned to him.
Assignee: sspitzer → caillon
Workaround: "File|Attach|Web Page..." in the Compose window still works and can
be used to add any kind of file (not just web pages).
Also, drag'n'drop works.
Drag-n-drop from where works?  I'm not using a window manager that has anything
to drag a file from.
d'n'd drom Nautilus, works. Just a data point, and a possible w/a for some people.
d'n'd from Nautilus, works. Just a data point, and a possible w/a for some people.
d&d from Moz to Gimp does not work - getting errors like this:

Opening 'The image "file:///home/dark/IMAGES2/8080/uio.jpg" cannot be displayed,
because it contains errors.' failed:

Unknown file type
The root issue is that the gtk2 filepicker doesn't work with opening multiple
files. nsIFilePicker.files doesn't work. The array it uses is never filled.
I hacked mailnews to not try multiple files, and it works.
The new filepicker is so extremely unusable that I have decided to stop using
Linux. That was not a small decision to make, took me some weeks. But the
filepicker under WinXP at least has an input widget. Found a nice free
X-copy/paste and windowraiser app - "True X-Mouse" - so I'm semi-happily using
Moz on WinXP now instead. Too bad the Gtk people have messed it up so bad. I
realize Mozilla.org isn't to blame. To all of you: Working as a "bugzilla
helper" has a nice aquaintance. I won't be participating any longer sine there
are plenty of "windows people" out there and I feel I don't have anything to
contribute with in that respect. So long, and thanks for all the fish ;)
I have to 2nd those comments about the new file picker being a horrendous step
backwards.  While I have no intention of dropping Linux, I'm really starting to
consider dropping Mozilla (which i've used since the pre-1.0 days),
I agree - can the bug 123197 checkin be reverted switching back from the native
gtk2 filepicker until it works better? The gtk2 filepicker is really terrible IMO...
Please, stop adding advocating comments! That won't help fix the bug in any way.
The gtk2 filepicker being unusable to you is a gtk2 problem, not a mozilla
problem. If you don't like gtk2, use a gtk1 build.
(and sorry for this spam)
If we intend to feature the GTK2 builds for 1.8a4, this will need to be fixed.
We may not feature those builds, so the blocking+ marker may not stick.
Flags: blocking1.8a4? → blocking1.8a4+
I agree that the GTK2 filepicker is pretty much unusable, and I think the
solution to that is to go back to using our own filepicker.
Patch coming tonight.
Status: NEW → ASSIGNED
Chris said he's going to be able to get to this soon. 
Attached patch Patch (obsolete) — Splinter Review
This should do it.
Comment on attachment 160037 [details] [diff] [review]
Patch

Sans the stray printf I forgot to remove before diffing (its since been nuked),
what do you say bryner?
Attachment #160037 - Flags: superreview?(bryner)
Attachment #160037 - Flags: review?(bryner)
I adressed the Gnome usability list about this issue, making noises.
http://mail.gnome.org/archives/usability/2004-September/thread.html
thread "The new file chooser".

Got a feeling my pleas were falling on deaf ears, and I had to drop the ball due
to travels - I don't have time for this. But something got out of it so far:

- Bug to bring back the text widget is
http://bugzilla.gnome.org/show_bug.cgi?id=136541

- Two new bugs filed:

http://bugzilla.gnome.org/show_bug.cgi?id=153211
http://bugzilla.gnome.org/show_bug.cgi?id=153212


A secret "backdoor" to the old textwidget exists in the Gtk2 version.
Not practical to use however: It needs to be opened via a hidden key shortcut:
Ctrl+L
Somebody out there believe it's sane to have to use the keyboard in order to use
the mouse to paste. Accessability people may think differently..
 
Comment on attachment 160037 [details] [diff] [review]
Patch

>+  nsCOMPtr<nsILocalFile> localfile = do_CreateInstance("@mozilla.org/file/local;1");
>+  if (localfile) {
>+    nsAutoString nativepath;
>+    CopyUTF8toUTF16(NS_STATIC_CAST(char*, filename), nativepath);
>+
>+    nsresult rv = localfile->InitWithPath(nativepath);

This could be replaced with:

nsresult rv = NS_NewNativeLocalFile(nsDependentCString(filename), PR_FALSE,
getter_AddRefs(localfile));

I think this is actually more correct since the GtkFileChooser docs suggest
that it returns the native filesystem encoding, not necessarily UTF-8.

>+void
>+nsFilePicker::ReadValuesFromFileChooser(GtkWidget *file_chooser)
>+{
>+  if (mMode == nsIFilePicker::modeOpen) {
>+    gchar *filename = _gtk_file_chooser_get_filename (GTK_FILE_CHOOSER(file_chooser));
>+    mFile.Assign(filename);
>+    g_free(filename);
>+  } else if (mMode == nsIFilePicker::modeOpenMultiple) {
>+    NS_NewISupportsArray(getter_AddRefs(mFiles));
>+    if (mFiles) {
>+      GSList *list = _gtk_file_chooser_get_filenames (GTK_FILE_CHOOSER(file_chooser));
>+      g_slist_foreach(list, ReadMultipleFiles, NS_STATIC_CAST(gpointer, mFiles));
>+      g_slist_free(list);
>+    }
>+  }

This should really change to not use nsISupportsArray, and instead use
nsCOMArray / NS_NewArrayEnumerator to return the nsISimpleEnumerator for
multiple files.
Attachment #160037 - Flags: superreview?(bryner)
Attachment #160037 - Flags: superreview-
Attachment #160037 - Flags: review?(bryner)
Attachment #160037 - Flags: review-
Attached patch Patch v2 (obsolete) — Splinter Review
Attachment #160037 - Attachment is obsolete: true
Attachment #160170 - Flags: superreview?(bryner)
Attachment #160170 - Flags: review?(bryner)
Attachment #160170 - Flags: superreview?(bryner)
Attachment #160170 - Flags: superreview+
Attachment #160170 - Flags: review?(bryner)
Attachment #160170 - Flags: review+
Attached patch One more timeSplinter Review
I had one more look and found two issues I wanted to catch before this landed:

  - We also need to read the (singular) filename in save mode.
  - We should make sure to clear the mFiles nsCOMArray when in single file mode

    and Truncate() the mFile string when in multiple mode.
Attachment #160170 - Attachment is obsolete: true
Comment on attachment 160170 [details] [diff] [review]
Patch v2

a=asa for 1.8a4 checkin.
Attachment #160170 - Flags: approval1.8a4? → approval1.8a4+
Attachment 160219 [details] [diff] checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Anyone know if this is broken on the 1.7 branch?
We're not putting the gtk2 file picker in 1.7, so this isn't needed.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: