71837 - Find and categorize all posing of UI from embedded code

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect, P1)

Description

[Dan Rosen]

This bug is a task of bug 65233 (specifically task #1 of
http://coot/embedding-dialogs.html#posedialogtasks). All UI posed from embedded
code must be found and categorized.

Task #3 on that list (which ought to be on mozilla.org real soon now) of
creating components/interfaces for each category of UI-posing functions should
probably be folded in here, but some work on solidifying how the component
system will work here (task #2) needs to be done first.

Comment 1

[Dan Rosen]

Attachment: Calls to nsIDOMWindowInternal::Open from C++

Comment 2

[Dan Rosen]

Attachment: Calls to nsIDOMWindowInternal::OpenDialog from C++

Comment 3

[Dan Rosen]

Some of the OpenDialog calls in this last patch we don't need to worry about...
Not sure which.

Comment 4

[Dan Rosen]

Attachment: Calls to window.open from JavaScript (incl. XBL)

Comment 5

[Dan Rosen]

Attachment: Calls to window.openDialog from JavaScript (incl. XBL)

Comment 6

[Dan M]

I'm adding our pared down list, derived from the above lists. We've broken them 
into "in" and "out" lists, "in" being the ones we believe are affected by being 
an embedded browser, "out" being the ones we believe are not, included for 
accountability.

Comment 7

[Dan M]

Attachment: raw list of affected dialogs; the "in" list

Comment 8

[Dan M]

Attachment: raw list of unaffected dialogs, the "out" list

Comment 9

[Dan Rosen]

I've done a first-cut categorization of affected dialogs... This list will
probably get hacked at a bit before everybody agrees on the componentization. At
that point, we can close this bug.

Comment 10

[Dan Rosen]

Attachment: Dialog categorization, revision 0.

Comment 11

[Dan Rosen]

Attachment: IDL for internally-posed UI components, based on info in previous attachment. includes nsIPrompt for comparison, excludes "gecko guts"

Comment 12

[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 13

[Dan Rosen]

Jud: Since Peter went and filed a whole bunch of bugs (now hanging off of 65233)
for each task, I figure we ought to make sure these are the right ones. Does the
"Dialog categorization, rev. 0" attachment look reasonable to you? (This modulo
the blizzard nsGtkMozRemoteHelper thing which isn't relevant anymore, btw.)

Comment 14

[Judson Valeski]

regarding some of the "in" dialogs that Gecko can spark.

-download progress
Not only would we throw this dialog, but we also need to know where to send
progress notifications. Should we hang a progress attribute off of this UI idl,
or how else would we handle it?

-Filepicker
How de we get the path back after throwing this dialog? Is the call blocking and
the path gets returned in an out parameter?

-Find Component
This one, to me, falls into the "Down into Gecko from the embedding app"
category. All dialogs that are sparked from a menu item (or accellerator key)
fall into this category. We currently have an interface that drives all the find
functionality (nsIWebBrowserFind). Conrad posted to npm.embedding on how to use
it (subject "Text searching is in" date 2/8/01).

Don't the following fall into the "Down into Gecko from embedding app" category?
-JavaScript console
-wallet/cookie

-uriloader
uriLoader and JS level window.open fall into a separate category in my mind.
They do top level window opening rather than "dialog" throwing. Am I right to
break these out into another category?

-widget property change notification opens "open location" dialog - XXX blizzard
Not sure what this one means.


If I'm missing something, please help me out.

Comment 15

[Dan Rosen]

Re: Jud's comments

> -download progress
> Not only would we throw this dialog, but we also need to know where to send
> progress notifications. Should we hang a progress attribute off of this UI
> idl, or how else would we handle it?

I dunno. You might want to throw the same comment in bug 73106.

> -Filepicker
> How de we get the path back after throwing this dialog? Is the call blocking
> and the path gets returned in an out parameter?

No, this wouldn't be modal. You'd have an OpenFilePicker which pops up the
window and provide a callback interface to implement, as far as I can tell. This
task has become bug 73134.

> -Find Component
> This one, to me, falls into the "Down into Gecko from the embedding app"
> category.

Actually, it turns out that this falls into the "we don't care if you don't"
category... See comments in bug 73138.

> All dialogs that are sparked from a menu item (or accellerator key)
> fall into this category.

You mean all dialogs that are sparked *only* by a menuitem or accel key (i.e.,
from our chrome). Some other dialogs can come both from user choice and from
within the bowels of embedded gecko... For example:

> Don't the following fall into the "Down into Gecko from embedding app"
> category?
> -JavaScript console
> -wallet/cookie

Opening the console would be a downcall, but the console itself can open windows
(view source, iirc). We figure that the JS console could very well be included
in an embedding app as-is, and therefore those call-sites must be fixed.

Wallet/cookie *definitely* have a couple up-calls, for when the wallet component
remembers or wants to remember form prefills, and for when a site wants to send
you a cookie. There are lots of other dialogs associated with those components
we don't have to worry about, but we do have a couple we need to fix up.

> -uriloader
> uriLoader and JS level window.open fall into a separate category in my mind.
> They do top level window opening rather than "dialog" throwing. Am I right to
> break these out into another category?

It's all the same to us... We call window.open() without knowing whether the URL
passed to that function is a browser window or a dialog. We need a function to
open up a browser window just like any other of these functions. If I'm not
mistaken, danm has done this already.

> -widget property change notification opens "open location" dialog
> Not sure what this one means.

Don't worry about it. Blizzard assures us it's not relevant.

Comment 16

[Dan Rosen]

I'm going to resolve this bug as fixed (read: "resolve this task as done"). The
further work is covered in bug 65233 and all the individual bugs it depends on.

Comment 17

[Michael Dunn]

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Comment 18

[David Epstein]

other issues covered in 65233.