162044 - Not able to get some nsIUriContentListener callbacks (from urILoader) in embedding app

Status: RESOLVED INVALID

(Core Graveyard :: Embedding: APIs, defect)

Description

[David Epstein]

Mozilla 1.1b Gecko 20020803. TestEmbed
nsIUriContentListener methods are implemented in BrowserImpl.cpp
1. Register nsIUriContentListener with AddWebBrowserListener() & iid. 
2. (optional) Register content listener from nsIUriLoader. But the problem here
is obtaining the content lstnr object for input into
nsIURILoader->RegisterContentListener().
3. recompile app.
4. Enter a url, load content, etc..
5. Try variations of these steps by switching order, omitting step 2, etc.
Result: Never obtain the nsIUriContentListener object. Callbacks for the iface
aren't kicking in, don't get notifications from the implemented methods.

Comment 1

[David Epstein]

I was able to create a urIContentListener object
(nsCOMPtr<nsIURIContentListener>
cntListener(NS_STATIC_CAST(nsIURIContentListener*, qaBrowserImpl)) and register
content listener as described above. But still don't get the notifications.
nsIURIContentListener btw is registered by the browser impl object in the test app.

Comment 2

[David Epstein]

I was able to get 2 notifications from attempted file save: IsPreferred() and
DoContent(). Will investigate other callbacks individually to try getting them
to work.

Comment 3

[David Epstein]

.

Comment 4

[David Epstein]

reopening to track the listener methods not able to get notifications for.

Comment 5

[David Epstein]

This bug is now tracking notifications using
URILoader->RegisterContentListener(). I'm only able to get responses for
IsPrefered() and DoContent(). I don't get anything for OnStartURIOpen(). Last
build used is Mozilla 1.2a Gecko 20020910.

Comment 6

[Chris Nalls]

Marking topembed+ as per topembed triage

Comment 7

[Judson Valeski]

.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Is this still a problem?  If so, any chance of posting either some code that
would reproduce this bug or, if said code is in the tree already, detailed
instructions on reproducing?

Comment 9

[David Epstein]

I've been off this project for a few months, so I haven't downloaded mozilla
builds for a while. This problem was occurring the last I checked (about 3
months ago!) and I would venture to say it's still happening. Charles said he
was able to run TestEmbed about a month ago.

To build and run TestEmbed, see:
http://lxr.mozilla.org/seamonkey/source/embedding/qa/testembed/README.TXT#170 

After launching TestEmbed:
1. Select "Tests > AddUriContentListener > Add from NsiUriLoader" menu item.
2. Make sure it says "NsiUriLoader->RegisterContentListener() test passed".
3a. Enter a url.
OR
3b. Try saving a doc or downloading something.
4. Check logfile in C:/temp/TestOutput.txt
5. Check to see any notification callbacks. i.e. nsIUriLoader->OpenURI().
Result: For 3a, no callbacks. For 3b, only 2 as noted above in Comment #2.
Expected: At the very least, should get something for OnStartURIOpen(). But it
should then check for a preferred content type (IsPreferred() is called when the
content type is specified, otherwise CanHandleContent() is called) and then
handle the content (DoContent() is called). Should also get parent listener
callback, etc.

Listener implementations are located at:
http://lxr.mozilla.org/seamonkey/source/embedding/qa/testembed/BrowserImpl.cpp#623

Also see bug 169254 and bug 169257

Comment 10

[Boris Zbarsky [:bzbarsky]]

Oh, well.  Looks like a Windows-only test app, Windows-only build instructions
that fail with an objdir build even on Windows... <sigh>.  I'm afraid I will not
be able to test this, lacking a windows build setup.  Darin? Seth?  Do you have
a Windows machine and cycles to test this?

Comment 11

[Boris Zbarsky [:bzbarsky]]

OK, I finally read through the code of this embedding app.

> At the very least, should get something for OnStartURIOpen()

Only if the listener corresponds to the entity that originated the load (eg the
docshell that originated the load).  Which is not the case in this case.

For 3a, you get no callback because the originating listener can handle the
load, so no other listener is even asked.

For 3b, you seem to be getting pretty much what you expected.

Parent listeners are only gotten if the originating window context doesn't
return a load cookie; in other words, if your listener does not correspond to
the originating context, this will never be called.

In short, the only purpose of RegisterContentListener is to register listeners
for things that normal docshells cannot handle; the only callbacks such
listeners should really expect are IsPreferred() and DoContent().

Marking invalid, since things are working correctly....

Comment 12

[Bill Filler]

I believe this is the same problem as bug 169257 which I think I've fixed (see 
my comments).