Here is another place which trash non ASCII data. I caught this when I trun on the assertion in 28424 and add "serach result" to the side bar, and type in some non ASCII text I think this is another cause of 22580 nsString::ToNewCString() line 671 nsGfxTextControlFrame::SaveState(nsGfxTextControlFrame * const 0x025565f4, nsIPresContext * 0x030d3b20, nsIPresState * * 0x0012d1d8) line 3225 + 12 bytes CaptureFrameStateFor(nsIPresContext * 0x030d3b20, nsIFrame * 0x02556590, nsILayoutHistoryState * 0x0332d080) line 1402 + 40 bytes FrameManager::CaptureFrameState(FrameManager * const 0x03025fc0, nsIPresContext * 0x030d3b20, nsIFrame * 0x02556590, nsILayoutHistoryState * 0x0332d080) line 1420 + 17 bytes FrameManager::CaptureFrameState(FrameManager * const 0x03025fc0, nsIPresContext * 0x030d3b20, nsIFrame * 0x02556550, nsILayoutHistoryState * 0x0332d080) line 1429 + 24 bytes FrameManager::CaptureFrameState(FrameManager * const 0x03025fc0, nsIPresContext * 0x030d3b20, nsIFrame * 0x02556510, nsILayoutHistoryState * 0x0332d080) line 1429 + 24 bytes FrameManager::CaptureFrameState(FrameManager * const 0x03025fc0, nsIPresContext * 0x030d3b20, nsIFrame * 0x025564cc, nsILayoutHistoryState * 0x0332d080) line 1429 + 24 bytes FrameManager::CaptureFrameState(FrameManager * const 0x03025fc0, nsIPresContext * 0x030d3b20, nsIFrame * 0x02556080, nsILayoutHistoryState * 0x0332d080) line 1429 + 24 bytes FrameManager::CaptureFrameState(FrameManager * const 0x03025fc0, nsIPresContext * 0x030d3b20, nsIFrame * 0x02556044, nsILayoutHistoryState * 0x0332d080) line 1429 + 24 bytes FrameManager::CaptureFrameState(FrameManager * const 0x03025fc0, nsIPresContext * 0x030d3b20, nsIFrame * 0x02556008, nsILayoutHistoryState * 0x0332d080) line 1429 + 24 bytes NS_IMETHODIMP nsGfxTextControlFrame::SaveState(nsIPresContext* aPresContext, nsIPresState** aState) { // Construct a pres state. NS_NewPresState(aState); // The addref happens here. nsAutoString theString; nsresult res = GetProperty(nsHTMLAtoms::value, theString); if (NS_SUCCEEDED(res)) { char* chars = theString.ToNewCString(); the theString.ToNewCString simply trash non ASCII data.

reassign to rods since cvsblame show me he check in those lines in 3.136 Put beta1 in the keyword since it block 22580.

The other odd thing in this code is it call the char* version of nsLinebreakConverter::ConvertLineBreaks , while sfraser did provide a PRUnichar* version of nsLinebreakConverter::ConvertLineBreaks This code should call ToNewUnicode() and use PRUnichar* as type instead

I am blamed for this because I copied the code from nsTextControlframe and I was compression the inheritence hierarchy. sfraser is the original author of this code and beter understands what is going on with the line breaking code etc. reassigning to sfraser

Simon -- we're marking this PDT+ based on the premise that it's just a matter of which linebreak converter to call. Assuming you can have this fixed by 3/3.

Bug 22580 might be a dup of this one.

No, 22580 is not a DUP of this. 22580 is DEPEND on this and others. 22580 is what user see. This is ONE of the problem caughted by whitebox QA.

Thanks, I didn't see it was already marked as a dependency, I just wanted to make sure that somewhere it was noted there is likely to be a connection between the two.

Added a diff attachment to the bug. ftang, please review. I think we also need to inspect all the other places where linebreak conversion happens on form control contents: nsFormFrame::URLEncode() nsFormFrame::ProcessAsMultipart() (2 places) Note that in none of these cases did I break i18n stuff. Before I put in the linebreak conversion code, we were already messing with char* data, instead of PRUnichar* data.

I don't believe that we should mess with the code in nsFormFrame at this point. That code needs i18n review.

Fix checked in

ftang, could you verify and comment? Thanks! -ckritzer

yes, this have been fix and check in. Verify 22580 can verfiy this bug.