Closed
Bug 75538
Opened 24 years ago
Closed 23 years ago
Add chrome support to embedding APIs
Categories
(Core Graveyard :: Embedding: APIs, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
Future
People
(Reporter: adamlock, Assigned: adamlock)
References
Details
Attachments
(3 files)
1.62 KB,
patch
|
Details | Diff | Splinter Review | |
3.21 KB,
patch
|
Details | Diff | Splinter Review | |
Patch adds nsIInterfaceRequestor to nsGlobalWindow. GetInterface returns docshell's nsIWebNavigation
2.38 KB,
patch
|
Details | Diff | Splinter Review |
Add support to the embedding APIs to support chrome content.
Amongst the things to do:
1. nsIWebBrowserSetup should have a property to set a new webbrowser
to host either chrome or content
2. Ensure it is possible to obtain the nsIWebNavigation interface for the
content area through public means, e.g. GetInterface on the content
DOM window
3. Add a "-chrome" arg to mfcEmbed that enables chrome support
4. Update mini-nav.xul to work and be part of embed.jar
5. Add some chrome tests to the smoke tests
Comment 1•24 years ago
|
||
What level of chrome support are we talking about? Beyond what's needed to show
chrome dialogs? In terms of those, I'm not sure why #1 is needed. PPEmbed
handles chrome dialogs without doing that.
I think we need to add support to the APIs and smoke tests to raise the profile
of our chrome support and ensure it is available to embedders through public
means.
Comment 3•24 years ago
|
||
One way we could do that is to have some embedding apps use XUL dialogs for
prompts and some use native. That will also demonstate how you can choose
whether you want chrome or native for a given UI iface and how easy it is to go
either way :-)
Comment 4•24 years ago
|
||
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
Comment 5•24 years ago
|
||
One thing we're missing for this is the ability to set the type of the
webBrowser to be chrome without using the nsIDocShellTreeItem iface. After
discussing with Adam, I added a way of doing this to nsIWebBrowserSetup.
This came up when using XUL dialogs for prompts in an embedded app. The XUL
dialogs which the embedding app made had no titles. Reason why is that
nsGlobalWindow::SetTitle will refuse to set the title is the docshell type is
not chrome. With this, patch, it works.
Comment 6•24 years ago
|
||
Comment 7•24 years ago
|
||
r=adamlock@netscape.com for both patches.
Comment 9•24 years ago
|
||
wfm. r=valeski.
What about the nsIWebNavigation issue adam raises?
Comment 10•24 years ago
|
||
Alright, so this patch only covers point #1 that Adam made.
Adam , can you explain a bit more about point #2?
I don't think point #3 is needed. The embedding app should make the window a
chrome window if it is told to do so given the flags to
nsIWebBrowserChrome::CreateBrowserWindow.
In terms of smoketests, we are covered already here since the prompt dialogs
(part of current smoketests) are now chrome dialogs in mfcEmbed.
Assignee | ||
Comment 11•24 years ago
|
||
Point 2 covers the fact that embedders will want to access nsIWebNavigation
on the chrome and on the primary (and other?) content docshells that it
contains.
Therefore we have to ensure there is a public way that they can obtain the
content docshells' nsIWebNavigation interfaces. It would be sufficient if they
can be obtained by walking the DOM window/document hierarchy and doing a
GetInterface for them. That just has to be verified.
Assignee | ||
Comment 12•24 years ago
|
||
I did some testing and I don't think it's possible to obtain nsIWebNavigation
without traversing the docshells at the moment.
Neither DOM windows nor documents implement nsIInterfaceRequestor and neither
exposes nsIWebNavigation. So while you can traverse the window/frames with
nsIDOMWindow and nsIDOMWindowCollection you can't obtain nsIWebNavigation for
the docshell associated with the window/frame. Perhaps nsGlobalWindow should
implement nsIInterfaceRequestor so interfaces on the docshell can be obtained
with GetInterface?
Can anyone think of another way we might be able to get nsIWebNavigation?
Assignee | ||
Comment 13•24 years ago
|
||
Assignee | ||
Comment 14•24 years ago
|
||
Patch allows the nsIWebNavigation to be obtained for any frame. For example with
the following pseudocode.
nsCOMPtr<nsIDOMWindow> window;
nsCOMPtr<nsIDOMWindowCollection> frames;
nsCOMPtr<nsIDOMWindow> contentWindow;
nsCOMPtr<nsIWebNavigation> conentNav;
webBrowser->GetContentDOMWindow(getter_AddRefs(window));
window->GetFrames(getter_AddRefs(frames));
frames->NamedItem("content", getter_AddRefs(contentWindow));
mContentNav = do_GetInterface(contentWindow);
mContentNav->LoadURI("http://foo.com/", LOAD_FLAGS_NONE);
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 15•24 years ago
|
||
FYI: as part of bug 79608 I added a GI to nsIDOMWindow
Index: dom/src/base/nsGlobalWindow.cpp
===================================================================
...
+ NS_INTERFACE_MAP_ENTRY(nsIInterfaceRequestor)
...
///***********************************************************************
+// GlobalWindowImpl::nsIInterfaceRequestor
//************************************************************************
+NS_IMETHODIMP GlobalWindowImpl::GetInterface(const nsIID & aIID, void
**aSink)
+{
+ NS_ENSURE_ARG_POINTER(aSink);
+ *aSink = nsnull;
+
+ if (aIID.Equals(NS_GET_IID(nsIDocCharset))) {
+ if (mDocShell) {
+ nsCOMPtr<nsIDocCharset> docCharset(do_QueryInterface(mDocShell));
+ *aSink = docCharset;
+ }
+ }
+ else {
+ return QueryInterface(aIID, aSink);
+ }
+
+ NS_IF_ADDREF(((nsISupports *) * aSink));
+ return NS_OK;
}
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Assignee | ||
Comment 19•23 years ago
|
||
Step 3 is done.
Probably still to do are:
1. Public mechanism for specifying chrome or content
2. More visibility for the embed-sample.jar & move it to embedding/samples
Assignee | ||
Comment 20•23 years ago
|
||
Marking bug fixed. Conrad's patch for bug 129288 should take care of 1) in my
last comment and 2) can be added to bug 72851
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 21•23 years ago
|
||
Checking the patches against 3/15/02 Mozilla debug build.
Adam or Conrad, I looked at the source checkin. I know these patches are old and
changes have been made since, but have a few questions before verifying this:
1) WRT patch id=31829, Looks like SETUP_CONTENT_IS_CHROME flag is superceded by
in SETUP_IS_CHROME_WRAPPER in the source:
mozilla/embedding/browser/webBrowser/nsIWebBrowserSetup.idl or
mozilla/embedding/browser/webBrowser/nsWebBrowser.cpp
Basically the same code snippet in nsWebBrowser.cpp is now under this flag. Can
you confirm?
2) WRT patch id=31830,
/cvsroot/mozilla/embedding/browser/powerplant/source/CBrowserShell.cpp,
CBrowserShell.cpp is:
a) missing #include "nsIWebBrowserSetup.h",
b) Code snippets for CBrowserShell constructors are different. For example,
there isn't mIsChromeShell() function called. And didn't find nsIWebBrowserSetup
use or anything like it in this file (specifically, this snippet is missing):
if (mIsChromeShell)
{
nsCOMPtr<nsIWebBrowserSetup> wbSetup(do_QueryInterface(mWebBrowser));
if (wbSetup)
wbSetup->SetProperty(nsIWebBrowserSetup::SETUP_CONTENT_IS_CHROME, PR_TRUE);
What happened to this?
also, cBrowserWindow.cp didn't include some patch code.
3) WRT patch id=32034, /cvsroot/mozilla/dom/src/base/nsGlobalWindow.cpp
is missing some source, but looks like code from Brian's #15 comment
(http://bugzilla.mozilla.org/show_bug.cgi?id=75538#c15) plus Adam's patch
accounts for the nsGlobalWindow changes.
But it looks like in nsGlobalWindow.cpp, GlobalWindowImpl::GetInterface(),
you're now directly returning the QI of nsIWebNav rather than the docShell (in
the patch). Could you confirm? Thanks.
I noticed that in nsGlobalWindow.h, "public nsIDomWindowEventOwner" is missing.
What happened to it?
Comment 22•23 years ago
|
||
> 1) WRT patch id=31829, Looks like SETUP_CONTENT_IS_CHROME flag is superceded by
in SETUP_IS_CHROME_WRAPPER in the source:
Yeah - I changed the name in the patch for bug 129288.
> 2) WRT patch id=31830,
/cvsroot/mozilla/embedding/browser/powerplant/source/CBrowserShell.cpp,
CBrowserShell.cpp is:
The code for PPEmbed changed so much since this patch, there's not much use in
comparing the PPEmbed portions of this patch to what went in with bug 129288.
Comment 23•23 years ago
|
||
Thanks Conrad. verifying against 3/15/02 0.9.9 Mozilla debug build
Status: RESOLVED → VERIFIED
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
•