73129 - Change plugin dialog posing to allow embedder override

Status: VERIFIED DUPLICATE of bug 83754

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Peter Trudelle]

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

Comment 1

[Peter Trudelle]

Adding mozilla0.9 keyword, dependency

Comment 2

[av (gone)]

Fixing the URL field.

Comment 3

[Dan Rosen]

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

Comment 4

[av (gone)]

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.

Comment 5

[Peter Trudelle]

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

Comment 6

[Judson Valeski]

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.

Comment 7

[Peter Lubczynski]

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.

Comment 8

[Peter Trudelle]

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

Comment 9

[Dan M]

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

Comment 10

[av (gone)]

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

Comment 11

[Dan M]

  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?

Comment 12

[Judson Valeski]

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.

Comment 13

[av (gone)]

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");

Comment 14

[Dan M]

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.

Comment 15

[av (gone)]

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.

Comment 16

[Peter Trudelle]

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

Comment 17

[Arun Ranganathan]

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

Comment 18

[av (gone)]

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

Comment 19

[Peter Trudelle]

-> dr, 0.9.2, since av is away.

Comment 20

[Peter Trudelle]

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

Comment 21

[Dan Rosen]

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?

Comment 22

[Peter Lubczynski]

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

Comment 23

[Dan M]

  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.

Comment 24

[Dan Rosen]

One "easy way out," coming right up.

Comment 25

[av (gone)]

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)

Comment 26

[Dan Rosen]

*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 

Comment 27

[Dan Rosen]

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.

Comment 28

[Dan Rosen]

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

Comment 29

[Dan Rosen]

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.

Comment 30

[Dan Rosen]

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.

Comment 31

[Dan Rosen]

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

Comment 32

[Dan Rosen]

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

Comment 33

[Peter Lubczynski]

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

Comment 34

[Peter Lubczynski]

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

Comment 35

[Peter Lubczynski]

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

Comment 36

[Judson Valeski]

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

Comment 37

[Peter Lubczynski]

Jud, this will probably be fixed with bug 83754.

Comment 38

[Peter Lubczynski]

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

Comment 39

[shrirang khanzode]

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