Closed Bug 211181 Opened 23 years ago Closed 23 years ago

[FIXr]URI fixup should work with UTF8 strings

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Details

Attachments

(1 file)

Patch coming up. This makes the code a little saner in a few places...
Attached patch Proposed patchSplinter Review
Comment on attachment 126795 [details] [diff] [review] Proposed patch smontagu has tested this and it does not regress bug 58866
Attachment #126795 - Flags: superreview?(darin)
Attachment #126795 - Flags: review?(adamlock)
Comment on attachment 126795 [details] [diff] [review] Proposed patch this looks ok to me. sr=darin with the following caveat... as for the PossiblyByteExpandedFileName code... think about it this way. if native charset code were zero padded, it would still look like valid UTF-16. moreover, a conversion of such to UTF-8 would be well defined. as such, the conversion back from UTF-8 to UTF-16 could very well reintroduce characters that are possibly byte expanded, so i think you should do away with your XXX comment unless someone can confirm that we never see incorrectly formated strings like this.
Attachment #126795 - Flags: superreview?(darin) → superreview+
I had simon test, and we do see incorrect strings like that. I'd like to change the XXX comment to say that the code _should_ be removed, once bug xxxxx is fixed. And I guess I should file that bug on intl? Simon?
Comment on attachment 126795 [details] [diff] [review] Proposed patch Aside from the xxx comment, it looks okay to me too. r=adamlock
Attachment #126795 - Flags: review?(adamlock) → review+
Summary: [FIX]URI fixup should work with UTF8 strings → [FIXr]URI fixup should work with UTF8 strings
The XXX comment I checked in: // XXXbz nsICmdLineService doesn't hand back unicode, so in some cases // what we have is actually a "utf8" version of a "utf16" string that's // actually byte-expanded native-encoding data. Someone upstream needs // to stop using AssignWithConversion and do things correctly. See bug // 58866 for what happens if we remove this // PossiblyByteExpandedFileName check. jshin? smontagu? Any ideas on where the perfidious non-converting code lives?
Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
This appears to have killed one of the camino builds: src/browser/BrowserWindowController.mm: In function `-[BrowserWindowController goToLocationFromToolbarURLField:]': src/browser/BrowserWindowController.mm:1175: no matching function for call to `nsIURIFixup::CreateFixupURI(nsAutoString&, int, nsGetterAddRefs<nsIURI>)' /builds/tinderbox/SeaMonkey/Darwin_6.6_Depend/mozilla/dist/include/docshell/nsIURIFixup.h:73: candidates are: virtual nsresult nsIURIFixup::CreateFixupURI(const nsACString&, unsigned int, nsIURI**)
Camino attempted fix checked in.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: