Need to change how plugin dialogs are invoked so they can be overridden by embedding clients. Some details below, more at URL above; danm will be happy to help and answer questions. UI Posed by Gecko (Up Calls) ============================ These are calls to window.open, in one form or another, which are relevant to embedding. They're split into calls and callers, where a call is considered to be a base-level call to window.open which should be API-ized like we're discussing, and a caller is something which currently uses window.open but should use one of these new APIs when they're created. I've tried to categorize these sensibly... Each category implies a UI-posing component with methods for each item marked "CALL" in that category. Items marked "CALLER" in a given category may imply a new method in that component (eg. the print dialog stuff), or may just be a caller of some other extant method in a different component (eg. the uri loader opening a new window). Plugins: /modules/plugin/default/windows/plugin.cpp#655 ??? /modules/plugin/default/mac/NullPlugin.cpp#1050 ??? /modules/plugin/default/os2/plugin.cpp#390 ??? /plugin/oji/MRJ/plugin/Source/EmbeddedFrame.cpp#130 ???

Adding mozilla0.9 keyword, dependency

Fixing the URL field.

Apologies for all the bug spam. For the detailed overview of this task, see danm's document: http://www.mozilla.org/xpfe/embedding-dialogs.html See my first cut at a component-wise categorization: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=27972 And if you want to laugh, see also my brainless incomplete IDL for these components: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=28175 dr

I think the biggest problem with the default plugin now is that it is not a component, it has just been stolen from the old 4.x world. And I am not sure how to achive the task without rewriting the whole plug-in to be an xp component. But from the other hand, the native dialog is not supposed to pop up if we have JavaScript enabled (if it does we can probably fix that). The JavaScript window should appear instead. So, may the fast solution will to change the default plugin so that it does not do dialogs at all and thus falls out of the scope of this problem.

Daniel? Jud? What do you guys think of Andrei's proposal?

if you don't throw UI, you're out of the loop and this bug goes away :-). however, isn't there some dialog we're supposed to throw? something like "do you want to go download the plugin"? If that's depricated, then pull it out completely and kill this bug.

adding my 2 cents.... There are actually a few dialogs. The one which I think we are talking about is the native window which comes up when we know where to get the plugin to ask the user for permission to go to the page or download the plugin. (#1) Screenshot: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=19628 Otherwise, if the attributs PLUGINSURL or PLUGINSPAGE are missing, the default plugin brings up an HTML type dialog (#2) which attemps to send the user to the Netscape Plugin Download page on Netscape.com. If there is no default plugin, there isn't anything to worry about as THAT dialog is XULed [UniversalDialog()] #3. I think Andrei is right. The real solution is to rewrite the whole plug-in to be an xp component but we are low on cycles now. A quicker solution would be to get rid of that dialog anway because the user will get another download confirmation before installing.

Embedding customers must have the option of overriding any XUL dialogs posed by Gecko too.

But UniversalDialog is part of the nsIPrompt suite (still), so that's covered already. As are all JS alerts (is that the JavaScript window you were referring to, av?) It *sounds* like you guys are saying we'll be covered and functional if you just get rid of the dialog...

No, I was talking about the Navigator window which pops up on javascript:openwindow.

javascript:window.open() is also already taken care of. What we're worried about here is whether a specific UI involving a unique dialog is involved. That would be something an embedding client might reasonably want to be able to override, which means component, API, and all that fun stuff we're talking about. window.open could mean that, if plugins uses it to launch an HTML dialog in browser's clothing. If that's not the case, or if you can reasonably omit the whole dialog, knowing that its absence will be accommodated by something else, we're OK. Else, we got problems. So Jud, if it comes to it, what's better? An omission in the official APIs, or some empty interface that's likely to have to change? av, how complex is the dialog? Is it possible to define an interface for running it and getting everything you need out of it with some degree of confidence?

depends on the dialog. plugins are generally an area that people wnat to completely override. we need to have a complete understnading of what dialogs plugins can throw, what "types" they are (native, xul, html, etc), and what they're for.

The native dialog which can be shown by the default plugin is very simple and has only OK and Cancel buttons on it (meaning whether or not to download plugin). Alternatively, the default plugin can issue the following command: javascript:window.open("http://cgi.netscape.com/cgi-bin/plug-in_finder.cgi? mimetype=sometype","plugin","toolbar=no,status=no,resizeable=no,scrollbars=no, height=252,width=626");

We're having a hard time arriving at a conclusion, here. OK, take four. Or five, or whatever it is. It sounds, once again, like perhaps you could use the nsIPrompt interface to pose a simple two-button alert. nsIPrompt is safe to use because it has already undergone the embedding-copacetic API-ification process.

No I cannot, at least I don't immediately see how. The default plugin has no access to the navigator services as it is not a component. What can relatively easily be done -- I can disable the native dialog making JavaScript window pop up in all cases. Then, it will not work with JavaScript disabled but we can say that somewhere, e.g. on the puzzle piece icon. Or just remove words 'Click here to get the plugin' in such a case.

Should this be reassigned, since AV is going on sabbatical?

nominating this for an nsbeta1 discussion, given the importance to embedding.

Solution is suggested, the fix is trivial. I am waiting for an order to provide a specific patch.

-> dr, 0.9.2, since av is away.

-> dr, 0.9.2, since av is away (this time actually doing the reassign).

trudelle or danm: I see two options stated here: use nsIPrompt, or kill the offending dialog. And according to Av, the first option isn't. I assume I'm supposed to kill the dialog, then?

Dan, keep in mind this is a different native dialog, on Window, Mac, and Linux. I don't see the big deal in having embedders override these dialogs. It's pretty simple to edit the platform specific resource files. IMO, the real way to fix this would be to re-write the Default Plugin (aka null plugin) as an XPCOM Plugin using XUL for the FE. There is a sample XPCOM Plugin in /mozilla/modules/plugin/test

I never did figure out what av wanted to do with this bug. av and I went back and forth for days, and I guess we never really understood each other. I vote against Peter's suggestion above. Our goal in providing hooks to embedders to override our dialogs is to allow them an overall unified UI. (Yes, they could pretty much do that by writing their own XUL, but we've been hearing that they'd rather write their own components and dialog resources and get the 100% solution. Go fig.) If they didn't mind XUL, they wouldn't have a need for any of these dialog APIs. That leaves two solutions. (1) Write a new component, stick the current XUL implementation behind it, and patch the code currently opening a window directly to use the component. You know the drill. No need to worry about different platform-native dialogs unless you want to provide overriding samples in the embedding testbed(s). Or (2) Take av's easy way out, outlined above. Personally I'd take av's 2001-04-18 11:58 suggestion.

One "easy way out," coming right up.

The following patch will leave the native dialog disabled on Windows: Index: plugin.cpp =================================================================== RCS file: /cvsroot/mozilla/modules/plugin/default/windows/plugin.cpp,v retrieving revision 1.4 diff -u -r1.4 plugin.cpp --- plugin.cpp 2001/04/18 00:05:20 1.4 +++ plugin.cpp 2001/06/01 20:20:49 @@ -426,7 +426,8 @@ dbgOut2("JavaScript %s", m_bJavaScript ? "Enabled" : "Disabled"); dbgOut2("SmartUpdate %s", m_bSmartUpdate ? "Enabled" : "Disabled"); - if((m_szPageURL != NULL) || (m_szFileURL != NULL) || !m_bJavaScript) + //if((m_szPageURL != NULL) || (m_szFileURL != NULL) || !m_bJavaScript) + if(0) { // we don't want it more than once if(m_hWndDialog == NULL)

*gulp* That doesn't seem right at all... I don't think you want to kill the dialog entirely, which is what that seems to do. Anyway, I've been thinking about an entirely different course this could take. Here's a (edited for context) copy of email I just sent out to a lucky few: --- Peter, Your idea of rewriting the null plugin using the new APIs, from scratch, honestly seems by far the best. What I would end up doing is exactly that, as well as either creating a new specific API tailored to posing the "get plugin" dialog (per 65233) or just using nsIPrompt to pose it (we can't just use XUL without an overridable API in front of it, as danm mentions). All that is fairly straightforward. But here's the thing: If I use the plugin APIs, I have to write a native window implementation (as is the case with null plugin currently, as well as the sample plugin you mentioned) which knows how to draw itself, handle clicks, and paint the fun little jigsaw-puzzle icon. I don't want to do that. It's silly. So what I'd naturally like to do is use XUL (or even HTML if it makes my life easier) for that purpose. It's trivial to create an area containing the little icon in XUL. But, of course, the plugin API doesn't let me do that -- a plugin has its own frame, and the plugin API provides hooks for me to fill in that frame, basically. And I don't want that capability at all -- I just want XUL to give me a frame corresponding to the supposed plugin area with the icon. So that raises the question I have here: Why do we need a default plugin? I can't think of any reason why it would actually be necessary. Instead, it should be trivial to hack the plugin backend (in the case of having to handle mime type "*/*") to just display a little XUL in an iframe, or some such, where we would normally have put the actual plugin. Of course, I'm saying all this completely ignorant of ... well ... just about everything. This is all just how it seems to me from the outside. Let me know whether this is correct thinking on my part, or whether I'm entirely wrong here. Thanks! dr

I just opened bug 83754 to remove the default plugin and replace it with a XUL implementation. Assuming that work is OK'ed, the work associated specifically with this bug will solely be either: - The design and implementation of an embedding-friendly API (ala bug 65233) for posing the "get plugin" dialog, or - Use of nsIPrompt to pose that dialog. I'll change the summary of this bug to reflect what I'm doing, when I actually know what I'm doing :) Again, I'm waiting for an OK in bug 83754.

Sooo, bug 83754 is now off in 0.9.3-land. I've requested input from aruner on whether this is still necessary for 0.9.2, or whether I can just wait until 0.9.3 on this (when this would fall out of the fix for 83754).

Sooo, I see "rtm stopper" just showed up in the status whiteboard. Can I get some clarification on that? Thanks. It also occurs to me that I'm still not certain (based on the comments in this bug alone) which of the dialogs we're actually concerned about.

Clearing "rtm stopper" status and nsbeta1 keyword. This bug is wanted *only* by embedding, not by seamonkey. If you're confused, please look at bug 65233, which this spun off of. Adding [wanted for embedding] to the status whiteboard. All I want to know is, is this *needed* for 0.9.2 by embedding, or can it wait for 0.9.3 when it would be much more easily fixed by removing the default plugin (83754)? Also, it occurs to me that we probably won't be embedding the default plugin at all, and that the dialog we need to make embedding-friendly is the one Peter Lubczynski mentions, which pops up a XUL dialog in the case that there is *no* default plugin.

->0.9.3. If anybody wants this done, they can give me consistent, useful information so I don't have to run around like a chicken with my head cut off.

[spam] working on toolkit: plugins bugs => plugins team.

Can someone provide more direction on how to triage this? Is this still [wanted for embedding]?

Jud/Marek/Chofmann: is this still wanted for embedding? Perhaps Future as I recall our main embedding customer is happy with the default plugin as it is because they have made changes? dunno...

I was told this is no longer needed for our main customer--->Future.

in order to have a complete dialog overriding story, we need this. please re-consider milestone. nominating 0.9.5.

Jud, this will probably be fixed with bug 83754.

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

mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"