There's some code in the webshell that is mangling URLs typed in to the location bar by using string concatenation (e.g. putting "http://" on the front, etc). This needs to be changed to use the nsIURI accessor routines. Extra credit: Use the Lynx expansion algorighm suggested by TenThumbs in the newsgroup ("news://news.mozilla.org/37950E9A.FFB06B5D%40cybernex.net").

I re-did this code so now necko url parsing (NS_NewURI) has first dibs on anything that comes through, and after each mangling. I left the raw mangling in there though as it's better at doing the string manipulation.

*** Bug 19270 has been marked as a duplicate of this bug. ***

I'm not sure, i understand this. This bug is marked as fixed, but it looks to me, as at least NS_NewURI did no completion (which is correct IMHO). My suggestion is a new function, that performs the completion (see bug #19270 for a description). Don't tell me, it's hacked into the webshell. Reopening for now, close it, if I misunderstood something.

*g* <URL:http://lxr.mozilla.org/seamonkey/source/webshell/src/nsWebShell.cpp#2366>. Clearing Resolution.

> There's some code in the webshell [...] This needs to be changed to use the > nsIURI accessor routines. Just saw this in the description. Can somebody explain me, why this was marked fixed?

Setting component/QAcontact.

It was marked fixed becuase the goal was to give necko first crack at the string. Necko is not responsible for application level string mangling. If you want to assume ownership of this bug and work on re-doing the application side string mangling, feel free.

Valeski, I already implemented the mangling I need, but it is (in parts) the same as the mangling in webshell. Maybe there'll more users. I would try to implement such a general function, if I had the framework. What do you think, is the best location for such a function (inside or outside Necko)?

definately outside necko. Necko provides an i/o facility and some URL parsing mechanisms based on specs. string munging is completely application specific. This stuff should actually live in the browser instance to further remove it from core functionality (such as the webshell). I've cc'd radha because I think there's already a bug on this.

I think we're confusing issues here. The code in the webshell deals with the location bar. There are special rules for that. We need to try http:<stuff>, ftp:<stuff>, file:<stuff>, keyword:<stuff> before giving up. In mailnews it's a completely different story. There, we need to notice <stuff> where stuff _begins_ with http:, ftp:, file:, etc. And if we find one of these, we need to make a link out of it. There is no trying to fix up the string to become a valid URL. Changing resolution back to fixed since we already have a bug for the mailnews thing.

Warren, No. We do try to complete the URL. A "www.mozilla.org" is linked to <http://www.mozilla.org>. Yes, we don't want keywords and propably not "file:", but we have some overlay with the code in webshell. Yes, we have a bug on the mailnews thing (bug #19270), but you marked it as duplicate of this one. *Now* I am confused. What am I supposed to do? Leave the code redundancy as it is?

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

old development issues