webhire.com - carriage return stripped during form submission



Tech Evangelism Graveyard
English US
15 years ago
3 years ago


(Reporter: Robert Devi, Unassigned)






15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

The following web site illustrates the bug:

If you load the above website into Phoenix, and enter the following lines of text:
to the textarea box labelled: "Resume (CV) Text:* " you will get the following
result when you press the "preview resume" button:
123 456 789

If you enter the same lines into Internet Explorer, I get the expected result
when I press the "preview resume" button:

I'm guessing that Phoenix (or any Gecko based browser) is submitting it's
textarea forms using Unix conventions for lines (i.e. each lines ends in a
newline), while Internet Explorer is using Windows conventions for lines (i.e.
each lines ends in a carriage return and then newline). The "preview resume"
recognizes Windows lines but not Unix lines so it messes up my resume when I
submit in Phoenix. Mozilla has the same bug. Changing the "user agent" doesn't help.

One might consider this to be a bug in the website since it shouldn't care what
type of newlines you're using, but it's a common bug (at least on job posting
sites) and I haven't found a way of working around it other than starting VMWare
and loading the website in Internet Explorer (I use Linux) or using Opera. 

Are there any options that I can set to give me the Internet Explorer behaviour
for newlines? Even enabling a hidden option or kludge would be good enough.

Note, on the surface, this bug appears related to 169964 and 145145, but it
isn't since you can reproduce the above bug with Netscape 4.77 too.

Reproducible: Always

Steps to Reproduce:
1. Load the selected web page 
2. Enter the following text in the textarea box labelled: "Resume (CV) Text:* "
3. Press the "Preview Resume" button.

Actual Results:  
The preview displays the following:
   123 456 789

Expected Results:  
The expected results are:
which is what you see in Internet Explorer and Opera.

Some forms, like job submission forms, cannot be mangled, this bug is forcing me
to use a non-Gecko browsers.
The linebreaks are submitted fine (look at the source of the page that comes
back).  But the page is not showing the text with style that would tell it to
preserve whitespace, so whitespace is collapsed as it normally is in HTML
(display issue only).

Are Mozilla and IE getting the same source back?  The same stylesheet?

Comment 2

15 years ago
I apologize for the long delay. There was a few personal emergencies I had to
deal with. I will be more responsive from now on.

Anyway, to answer your question, yes, both browsers recieve the same HTML. I've
attached the PreviewResume() javascript. I suspect the culprit is this line:
                var reLineFeed = new RegExp("\r\n", "g");
                vText = vText.replace(reLineFeed, "<BR>\r\n");
where vText contains the form data for the multi-line resume. My guess is that
newlines in form data are converted to Unix-style.

If this is the case, then changing the form data behaviour to fix this may break
some Mozilla pages that assume that newlines end with only "\n".

Would it be possible to create an option that allows you to change the line
termination behaviour of forms to confirm to the to Microsoft web browser style?
Ideally that behaviour would be active when you change the User-Agent to IE, but
I would be happy with a hidden option that could only be accessed with the
Mozilla config file or "Advanced Preferences" Mozilla/Firebird plugin into the
Mozilla registry.

        function PreviewResume()
                // convert any special Microsoft characters and update the
resume text on the form
                // get the resume text to pass into the preview dialog
                var strResume = new
                // preserve white space formatting
                strResume = replaceMultipleSpaces(strResume);
                // now put it into the hidden variable for the preview dialog
                document.forms["PreviewFrm"].RESUME.value = strResume;

		// ...
                // if there is an AcctLogo, create the IMG for the preview dialog
                var vAcctLogo = "ati";
                if ( vAcctLogo != "" )
                        var vImg = "<img id='LogoImage' ";
                        vImg += "src='/orbimages/ati";
                        vImg += ".gif'></img>";
                        document.forms["PreviewFrm"].vLogoGIF.value = vImg;
                var WinObj; //window object
                var WindowURL = "resume_preview.asp";
                var WindowName = "PreviewWindow";
                //send the user to the url in the window named
                WinObj = window.open(WindowURL, WindowName,

        // replace multiple spaces and tabs with non-breaking white space
        function replaceMultipleSpaces( vResumeText )
                var vText;
                var reHTML = new RegExp("</HTML>", "i");
                if ( vResumeText.search(reHTML) > -1 )
                        return vResumeText;
                // create a RegEx for the space and replace
                // Note:  This replaces 2 spaces with NBSPs.  The reason for
this is to allow
                // line wrapping to occur.  If all single spaces are replaced,
there is no line wrapping.
                var reSpace = new RegExp("  ", "g");
                vText = vResumeText.replace(reSpace, "&nbsp;&nbsp;");
                // create a RegEx for the tab and replace
                // Note: this replaces a tab with 8 NBSP.
                var reTab = new RegExp("        ", "g");
                vText = vText.replace(reTab,
                // create a RegEx for crlf and replace
                var reLineFeed = new RegExp("\r\n", "g");
                vText = vText.replace(reLineFeed, "<BR>\r\n");
                return vText;
> I suspect the culprit is this line:
> var reLineFeed = new RegExp("\r\n", "g");

Yep, it is.  The DOM spec explicitly defines that all newlines in text nodes in
a DOM tree are to be '\n'.  This eliminates platform dependence of those
newlines and such (that is, they must be '\n' on all platforms, including
Windows).  Changing this would be highly nontrivial, since a lot of
Mozilla-internal code depends on this invariant to function properly, in
addition to, as you said, various web sites that are following standards....

Over to Parser, since that's where the changes would have to start, but I
suspect that this will just end up in Evangelism.
Assignee: form-submission → harishd
Component: Form Submission → Parser
QA Contact: ashishbhatt → dsirnapalli
Sending to Tech Evangelism, leaving as unconfirmed since I'm not sure of the
proper component. Per comment 3, our current behavior is correct per the DOM spec.
Assignee: harishd → english-us
Component: HTML: Parser → English US
Product: Browser → Tech Evangelism
QA Contact: dsirnapalli → english-us
Version: Trunk → unspecified

Comment 5

14 years ago
contact info webmaster@webhire.com

They should replace the following 
var reLineFeed = new RegExp("\r\n", "g");
var reLineFeed = new RegExp("[\r\n]+", "g");
Ever confirmed: true

Comment 6

14 years ago
Conforming summary to TFM item 10 at 
Summary: carriage return stripped during form submission → webhire.com - carriage return stripped during form submission

Comment 7

4 years ago
URL is obsolete.
Last Resolved: 4 years ago
Resolution: --- → INVALID
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.