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:

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

-> i'll investigate this one... blizzard, any advice would be greatly appreciated!

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...

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.

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...

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

> 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.

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...

> 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.

sorry, i won't have time to help with this for gecko 1.8. -> future, helpwanted!

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

Embedding: GTK Widget isn't a thing, closing.