645978 - nsIURIContentListener vs nsIContentHandler in Firefox4

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[passfree]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.27 (KHTML, like Gecko) Chrome/12.0.712.0 Safari/534.27
Build Identifier: 2.0

Firefox3 uses nsIContentHandler to handle the document loading process. In Firefox4 this mechanism is replaced with nsIURIContentListener. This creates several problems, imho.

First, the nsIURIContentListeners are called way after nsIContentHandlers. This perhaps is not a huge performance hit, however, what bothers me is that by using nsIURIContentListeners instead of nsIContentHandlers the resource (in case of http) is requested twice. The reason for this is because when we start loading the resource necko needs figure out the mimetype, so a request is send to get the headers. Later on nsDocumentOpenInfo::DispatchContent starts searching for right candidates to handle the content. If nsIContentHandlers are used, the channel stream is given which subsequently needs to be passed into something like a docShell. If nsIURIContentListeners are used, the first request is essentially dropped. In Firefox4, for example, URI from the channel will be extracted and passed to the browser.

Perhaps there is a good reason why this is setup this way. 

More information can be found here: https://developer.mozilla.org/en/Document_Loading_-_From_Load_Start_to_Finding_a_Handler
There is a discussion here: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/9fd0321ac06ef790

Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

> In Firefox4 this mechanism is replaced with nsIURIContentListener.

nsIURIContentListener has been around since late 1999.  So nothing has changed here in the Firefox 4 timeframe in the back end; I'm pretty sure nothing has changed in the front end either.

> First, the nsIURIContentListeners are called way after nsIContentHandlers.

This is not the case.  nsIContentHandler is called after nsIURIContentListener.

> using nsIURIContentListeners instead of nsIContentHandlers the resource (in
> case of http) is requested twice

That's exactly backwards.  The resource is only requested twice if you have an nsIContentHandler that requests the resource a second time.

> If nsIContentHandlers are used, the channel stream is given which
> subsequently needs to be passed into something like a docShell.

Again, you have that backwards.  This is what happens when an nsIURIContentListener is used.

> If nsIURIContentListeners are used, the first request is essentially dropped.

Again, this happens if you use nsIContentHandler.

I'm not sure this bug is useful as filed; given all the factual inaccuracies I can't quite tell what the bug is about...

Comment 2

[Ioana (away)]

Reporter, please reopen this bug if you can give a more accurate description of what you want here.