76585 - Need to be able to use embedding APIs in Mozilla

Status: RESOLVED INCOMPLETE

(Core :: DOM: Navigation, defect)

Description

[Simon Fraser [no longer active]]

We currently have a massive divergence between the way things are done in 
Mozilla, and the way that we tell embedders to do things (how to get to the 
various interfaces etc).

We need to start transitioning Mozilla to using something like the embedding 
APIs. I think an essential first step is to have something implement 
nsIWebBrowser in mozilla, so that we can start to use QI and GI to get at other 
nsIWebBrowser* interfaces. Right now, the only place to hang these is off of 
nsDocShell, which is not the correct place.

I have needs for this for doing Find, and for the editor embedding APIs. It's 
pretty important for me.

Comment 1

[Adam Lock]

The web browser is the container of all docshells and the topmost tree item. The 
closest equivalent in Mozilla is probably the XUL window even though it 
currently does not act as the topmost item in the docshell tree. If we did want 
to reuse web browser in Mozilla I think that nsXULWindow could be modified with 
significant work so it instantiated a web browser object to handle its chrome 
and content instead of implementing it's own tree owner classes.

We could reuse some other stuff things from embedding. 

1. nsIWebBrowserPersist & web browser persist object. Make it a component and 
rework the xfer object to use it.
2. nsIWebBrowserFind & find object. Make it a component or at least reuse the 
interface in the xpfe find component and deprecate nsISearchContext.
3. nsIWebBrowserPrint should be used instead of nsIContentViewFile for print 
operations.

Comment 2

[Judson Valeski]

cc'ing self and bryner (who has expressed interest in this)

Comment 3

[Simon Fraser [no longer active]]

I already have changes to reuse nsIWebBrowserFind for mozilla. See bug 68307

Comment 4

[Adam Lock]

Adding a dependency to bug 77909 which covers some some work to 
nsWebBrowserPersist and is relevant to this bug. 

Comment 5

[basic]

Changing platform

Comment 6

[Conrad Carlen (not reading bugmail)]

No, this is *not* a Mac-specific problem. What makes you think this? Changing
the platform back to all.

Comment 7

[rpotts (gone)]

is this going to morph into a meta-bug for tracking all of the issues of
transitioning the mozilla browser over to the embedding APIs?  

or should i just attach one gigantic patch - and be done with it :-)

-- rick

Comment 8

[Benjamin Smedberg]

While we might want to do something like this, the bug isn't tracking anything useful.