| moz.build |
|
1023 |
| nsAutoWindowStateHelper.cpp |
nsAutoWindowStateHelper *********************
************************************************************** |
2118 |
| nsAutoWindowStateHelper.h |
Helper class for dealing with notifications around opening modal
windows.
|
898 |
| nsDialogParamBlock.cpp |
|
2170 |
| nsDialogParamBlock.h |
|
1313 |
| nsIDialogParamBlock.idl |
An interface to pass strings, integers and nsISupports to a dialog
|
1286 |
| nsIOpenWindowInfo.idl |
nsIBrowsingContextReadyCallback.browsingContextReady() is called within
nsFrameLoader to indicate that the browsing context for a newly opened
window/tab is ready.
|
2566 |
| nsIPromptCollection.idl |
This interface contains various specialized prompts that the app can
implement.
|
1549 |
| nsIPromptFactory.idl |
This interface allows creating various prompts that have a specific parent.
|
701 |
| nsIPromptService.idl |
This is the interface to the embeddable prompt service; the service that
implements nsIPrompt. Its interface is designed to be just nsIPrompt, each
method modified to take a parent window parameter.
Accesskeys can be attached to buttons and checkboxes by inserting an &
before the accesskey character in the checkbox message or button title. For
a real &, use && instead. (A "button title" generally refers to the text
label of a button.)
One note: in all cases, the parent window parameter can be null. However,
these windows are all intended to have parents. So when no parent is
specified, the implementation should try hard to find a suitable foster
parent.
Implementations are free to choose how they present the various button
types. For example, while prompts that give the user a choice between OK
and Cancel are required to return a boolean value indicating whether or not
the user accepted the prompt (pressed OK) or rejected the prompt (pressed
Cancel), the implementation of this interface could very well speak the
prompt to the user instead of rendering any visual user-interface. The
standard button types are merely idioms used to convey the nature of the
choice the user is to make.
Because implementations of this interface may loosely interpret the various
button types, it is advised that text messages passed to these prompts do
not refer to the button types by name. For example, it is inadvisable to
tell the user to "Press OK to proceed." Instead, such a prompt might be
rewritten to ask the user: "Would you like to proceed?"
|
24984 |
| nsIWindowWatcher.idl |
nsIWindowWatcher is the keeper of Gecko/DOM Windows. It maintains
a list of open top-level windows, and allows some operations on them.
Usage notes:
This component has an |activeWindow| property. Clients may expect
this property to be always current, so to properly integrate this component
the application will need to keep it current by setting the property
as the active window changes.
This component should not keep a (XPCOM) reference to any windows;
the implementation will claim no ownership. Windows must notify
this component when they are created or destroyed, so only a weak
reference is kept. Note that there is no interface for such notifications
(not a public one, anyway). This is taken care of both in Mozilla and
by common embedding code. Embedding clients need do nothing special
about that requirement.
This component must be initialized at application startup by calling
setWindowCreator.
|
6886 |
| nsOpenWindowInfo.cpp |
|
2616 |
| nsOpenWindowInfo.h |
|
1545 |
| nsPIWindowWatcher.idl |
Private "control" methods on the Window Watcher. These are annoying
bookkeeping methods, not part of the public (embedding) interface.
|
6797 |
| nsPromptUtils.h |
@file
This file defines some helper functions that simplify interaction
with authentication prompts.
|
4352 |
| nsWindowWatcher.cpp |
nsWatcherWindowEntry **********************
************************************************************** |
91100 |
| nsWindowWatcher.h |
|
4015 |
| test |
|
|