(Core Graveyard :: Embedding: APIs, defect)

The embedding API is the set of functions that an external application uses to host an instance of the layout engine within itself. The embedded layout engine provides services for rendering web content (HTML, XML, CSS, etc).
Disabled per: https://bugzilla.mozilla.org/show_bug.cgi?id=1538959

Works for me pre and post 0.9 branches.
Have you set a breakpoint on the method to examine aRequest? There should be no
reason for the QI to fail unless the aRequest pointer is nsnull, points to some
other kind of object or perhaps the proxy is screwed up.
If it's any of these things, it may be instructive to walk up and down the stack
a bit to find out why it is so.

I'm seeing this too in mozilla. inline images are not getting causing
OnStateChange() notifications to propegate. I suspect this is an artifact of
images no longer using the uriLoader for loading. cc'ing pavlov.

rpotts and I were talking and are thinking that this is a result of one of the
following:
1. imagelib isn't adding it's requests to a loadgroup.
2. imagelib isn't adding it's requests to the correct loadgroup.
3. imagelib is adding it's requests to a loadgroup w/ the background flag set
(which would remove it from OnStateChange()) callbacks.

a proxy represents each individual request.. those get added to the loadgroup of
the requestor.
the channel itself is not in any loadgroup. perhaps this is the problem. if
so, i don't know how to fix it. the channel can't be added to a loadgroup,
since you could have multiple requests with different loadgroups... adding the
channel to the loadgroup would also mean that you could cancel the channel
directly, which would break different document, same image, different loadgroup
stuff.

The notification callbacks (nsIProgressEventSink in particular) are used to
generate the OnStateChange(TRANSFERRING) notification and the
nsIWebProgress::OnProgress(...) notifications.
It would sure be nice to get progress info for image downloads :-)

On thing that is not clear to me w/ this, is although we're not producing image
level onStateChange notifications, the mozilla browser UI seems to produce a
progress meter that includes the images (ie. it doesn't complete until all the
images have come in).
the docloader produces nsIWebProgressListener callbacks based on
nsIProgressEventSink, therefore I'm starting to wonder if this is fallout from
the fact that imagelib no longer creates channels, rather than it not providing
notification callbacks. I wonder if we're failing in the docloader somewhere
trying to get a channel for an image, and subsequently we're not producing an
OnStateChange() for it.

cc'ing darin (explicit question for you below)
I was right in that we are indeed getting the OnStateChange() notification for
image requests. The opperative word there is _requests_. imagelib doesn't impl
channels which is what most OnStateChange() consumers are trying to use to get
some user presentable string looking like a URI out of the callback.
So, the semantic for nsIWebProgressListener implementors who want to get a uri
string out of the requests that come in through the callbacks is that they need
to call the nsIRequest.idl "name" attribute (->GetName(PRUnichar **)) on the
request. That reflects some meaningful string for presentation.
This semantic has the following affect on callers... where they were once using
"char*" w/ nsIURI->GetSpec(), they now need to use "PRUnichar*" w/
nsIRequest->GetName(). Darin, we were talking about the problem of exposing URI
specs as char* or PRUnichar* a week or two ago. Enforcing this new model would
obviously force users into the "uri's are PRUnichar*'s at the UI level" world.
Thoughts?
This model also requires mozilla to provide "names" that people want. Namely
URI's when possible. I'm attatching a patch to scrape some imagelib specific
strings out of the name attribute so we return a raw URI instead.