Closed
Bug 71837
Opened 24 years ago
Closed 24 years ago
Find and categorize all posing of UI from embedded code
Categories
(Core Graveyard :: Embedding: APIs, defect, P1)
Core Graveyard
Embedding: APIs
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: dr, Assigned: dr)
References
Details
(Keywords: embed)
Attachments
(8 files)
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.
Some of the OpenDialog calls in this last patch we don't need to worry about...
Not sure which.
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.
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.
Assignee | ||
Comment 10•24 years ago
|
||
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
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
Keywords: embed
Assignee | ||
Comment 13•24 years ago
|
||
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•24 years ago
|
||
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.
Assignee | ||
Comment 15•24 years ago
|
||
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.
Assignee | ||
Comment 16•24 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 17•24 years ago
|
||
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•