(In reply to comment #8)
> >+ rv = aURI->GetOriginCharset(charset);
> This could be empty - in which case it's assumed to be UTF-8
Ok. Defaulted to "UTF-8" if empty.
> >+ (void)textToSubURI->UnEscapeURIForUI(charset, utf8URISpec, uriSpec);
> * escaping back the result (unescaped string) is not guaranteed to give the
> original escaped string
E.g., escape(unescape("hi there")) -> hi%20there
But that's fine because we're showing this to the user which s/he could have typed in without us unescaping.
> >+ StringHead(uriSpec, HISTORY_URI_LENGTH_MAX));
See bug 319004.
> I do believe that if we are changing how we store information in the database
> that we also need to migrate existing data.
Added migration code and migration testcase. This should also fix bug 391691.
Created an attachment (id=305310)
v1.1
(In reply to comment #8) Charset( charset) ;
> >+ rv = aURI->GetOrigin
> This could be empty - in which case it's assumed to be UTF-8
Ok. Defaulted to "UTF-8" if empty.
> >+ (void)textToSub URI->UnEscapeUR IForUI( charset, utf8URISpec, uriSpec);
> * escaping back the result (unescaped string) is not guaranteed to give the
> original escaped string
E.g., escape(unescape("hi there")) -> hi%20there
But that's fine because we're showing this to the user which s/he could have typed in without us unescaping.
> >+ StringHead(uriSpec, HISTORY_ URI_LENGTH_ MAX));
See bug 319004.
> I do believe that if we are changing how we store information in the database
> that we also need to migrate existing data.
Added migration code and migration testcase. This should also fix bug 391691.