Cannot download files with GtkMozEmbed widget and Mozilla embedding API

RESOLVED WONTFIX

Status

P4
major
RESOLVED WONTFIX
15 years ago
2 months ago

People

(Reporter: christophe_cornu, Unassigned)

Tracking

({helpwanted})

Trunk
x86
Linux
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: 

Build the full Mozilla source tree.
Start TestGtkEmbed in dist/bin
Point to the above URL (or any URL to download a zip file)

With a 1.4 build: a dialog pops up with 2 options to "Open it with" and "Save 
to disk". It is not possible to change the selection and the browse button 
does not trigger anything. When clicking OK, the file does not appear to be 
downloaded. This dialog is populated from the 
nsIWindowCreator.CreateChromeWindow callback. Expected: being able to select 
the options in the dialog and have the file saved on the machine
Similar behaviour with following versions.

What is the strategy that should be followed by Mozilla embedders - to be able 
to download files and save them ? And to get a - or provide our own -  dowload 
file dialog that allows the user to select where to save the file to.

Thanks for any hint. This problem is currently causing the java SWT Browser 
widget to not support file download on Linux. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=60975



Reproducible: Always
Steps to Reproduce:
(Reporter)

Comment 1

15 years ago
Darin: this is an important case for us. Maybe we simply overlooked the proper 
way to handle file download, any advice is appreciated.

Comment 2

15 years ago
-> i'll investigate this one... blizzard, any advice would be greatly appreciated!
Assignee: blizzard → darin
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

15 years ago
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
No ideas here.  Haven't looked into it.
embeddors usually implement nsIHelperAppDialog/nsIProgressDialog with
appropriate contract ids, and are responsible for showing the dialog.

I suppose that mozilla's implementation should also work for embeddors (unless
you use --disable-xul...), not sure why it does not...

Comment 5

15 years ago
Christophe:

so, you may simply want to add an implementation of nsIHelperAppDialog /
nsIProgressDialog to SWT.  these are currently implemented in mozilla under
embedding/components/ui/.

of course, it is probably a good idea for us to add some sort of corresponding
callbacks for gtkmozembed consumers.
So, in my gtk2 build the behaviour is as follows: This dialog mostly works,
except when it needs a(n xul) file picker. it fails to do stuff when used from
embedding, there seem to be several problems.

when I made mozilla use caillon's new gtk2 native file picker, things worked.
download manager inside a testgtkembed window does look cute :) (but not in a
way that would be acceptable to a real product)

using "open with default application" also worked fine.


Gtk1:
filepicker doesn't work either. no native filepicker to use.
however, "open with default application" also works fine.

download manager looks no less cute ;)


Note that I was able to change the selected radio button.


This testing was done using current CVS.
(Reporter)

Comment 7

15 years ago
Thanks Christian and Darin.

I will implement/test with nsIHelperAppLauncherDialog as suggested. This API 
is not frozen and it has changed between Mozilla 1.4 and 1.6 (extra argument 
in Show) so I needed to be sure this is the best option at the moment.
(In reply to comment #7)
> I will implement/test with nsIHelperAppLauncherDialog as suggested. This API 
> is not frozen and it has changed between Mozilla 1.4 and 1.6 (extra argument 
> in Show) so I needed to be sure this is the best option at the moment.

Yeah... we really should consider freezing this interface (and moving the file
into uriloader/exthandler). show's third argument may need to change its type
though... hm...
(Reporter)

Comment 9

15 years ago
Can anyone recommend a way to determine at runtime which version of Mozilla an 
embedder is binded to? To determine if we are executing against Mozilla 1.4, 
1.4.2, or 1.5 etc. Thanks,
Chris

Comment 10

15 years ago
> Can anyone recommend a way to determine at runtime which version of Mozilla an 
> embedder is binded to? To determine if we are executing against Mozilla 1.4, 
> 1.4.2, or 1.5 etc. Thanks,

Chris, there is no direct API to query the Mozilla version.  You could parse the
UserAgent string, but perhaps you don't need to resort to that.  Isn't Eclipse
reading /etc/gre.conf to determine the location of the GRE?  That file has the
Mozilla version number in it.
(Reporter)

Comment 11

15 years ago
Unfortunatly, the GRE file cannot be relied upon. It is not always there and 
the user can set the LD_LIBRARY_PATH etc.
Can you point me toward code that looks up the UserAgent string using frozen 
API?

About memory leaks. The instance of nsIHelperAppLauncherDialog provided by the 
embedder is expected to be freed - i.e. its ref count goes down to 0 - after 
the download complete or when the download is cancelled in some ways, right? 
I've got some different results when embedding different Mozilla versions 
1.4 .. 1.6 on Windows and Linux. Looks like you worked in that area with bug 
152224 for Mozilla 1.7. Are there known leak issues in past versions? 
Otherwise I could very well be doing something wrong.

Many thanks for the help...

Comment 12

14 years ago
> Unfortunatly, the GRE file cannot be relied upon. It is not always there and 
> the user can set the LD_LIBRARY_PATH etc.

yeah, good point.


> Can you point me toward code that looks up the UserAgent string using frozen 
> API?

i don't know of a good way to do this using frozen interfaces.  you could access
nsIHttpProtocolHandler::misc, which is the "rv:1.7" string that you see in the
UserAgent string.

i'd like to implement a better solution.

Comment 13

14 years ago
sorry, i won't have time to help with this for gecko 1.8.

-> future, helpwanted!
Keywords: helpwanted
Priority: -- → P4
Target Milestone: mozilla1.8beta1 → Future
I believe biesi is working on getting the relevant APIs ready to freeze....
who knows, maybe I'll actually get to all that before 1.8b2
Depends on: 270895, 270897

Updated

13 years ago
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: pavlov → gtk-widget
Target Milestone: Future → ---
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
Embedding: GTK Widget isn't a thing, closing.
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.