<Moved enhancement from bugsplat 80213. Relevant contents are pasted here. Sorry if this is misassigned. Taking a first stab at these new components.> You used to be able to call the mailbox from a Navigator window by using the command "mailbox://" but this doesn't work in Communicator anymore. This needs to call up the Messaging Window - can this be put in.... thanks jones@netscape.com x4573

This sounds badly broken. M6 to make sure URL dispatching is right in 5.0

Phil, we won't have any url dispatching from the browser until Necko is done. I'm pushing this out to M7 if not later as I don't expect this functionality from necko by M6.

I'm surprised that deciding which window to run a URL in is covered by necko. Warren, is it?

This is the url dispatching stuff. The url would get loaded from the url bar into netlib which looks at the protocol scheme and kicks the url out to a registered protocol handler for that scheme. At least that was my take on this bug...

It sounds like the current netlib isn't doing this. It works in necko...!

But but but...in 4.x there's a bunch of code in each FE to look at each URL before giving it to netlib. The FE decides (with help from the libmsg backend) what kind of window to run the URL in. It's this code which brings up a mail window instead of allowing the mailbox:// URL to run in the browser window. Is this kind of thing really necko's responsibility?

Ok, I misunderstood. Necko's responsibility is to find the protocol handler for the URL, and get the data back to the application. It's the application's responsibility to provide a context for loading the URL -- one that is wired up to talk to the right application window. I don't have a work item for that on the schedule (although maybe I should).

Yes, it seems like we should define some interface between necko and the application which knows what type of window is required for a given URL.

I don't think it's so much an interface that knows what type of window is required, but some implementations of stream handlers that upon receiving the data direct it to the appropriate application window. The app would choose the appropriate stream handler as part of making the url request. I've added a week to our schedule to help with this task.

We're not going to be there in M7 for this bug pushing it down the pipe until post necko integration.....

Moving all Mail/News Networking bugs to Mail/News Networking-Mail This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will fix those bugs.

I still have some issues about protocol registratoin that need worked out with the necko team before this can become a reality. In particular, I can't support the nsIChannel interface in its current form for pluggable protocols like mailbox because they aren't stream oriented. Warren and I have talked briefly about pulling out the stream specific interface methods in nsIChannel. I'll follow up on this post necko landing.

I think this needs to be fixed before PR1 - I noted this in the Status Whiteboard

Scott,isThisFixedWithURLDispatching?

Mail Review recommends not in this release. Marking M20.

Moving target milestone to "future" to be reviewed at a later time

This works for imap:// at least. Maybe it's time to skim through the futured bugs and see what's still relevant.

obsolete?

(In reply to comment #17) > This works for imap:// at least. Maybe it's time to skim through the futured > bugs and see what's still relevant. imap://me@blah/Drafts doesn't do anything for me, nor does it produce an error message ditto mailbox://

As far as I can tell, this is a Seamonkey-type request. Feel free to move back if it isn't.

WFM on Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9pre) Gecko/2008050913 SeaMonkey/2.0a1pre