Closed
Bug 202574
Opened 21 years ago
Closed 10 years ago
webhire.com - carriage return stripped during form submission
Categories
(Tech Evangelism Graveyard :: English US, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: g2devi, Unassigned)
References
()
Details
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: http://resumebuilder.webhire.com/resume_add.asp?company=ati If you load the above website into Phoenix, and enter the following lines of text: 123 456 789 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: 123 456 789 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:* " 123 456 789 3. Press the "Preview Resume" button. Actual Results: The preview displays the following: 123 456 789 Expected Results: The expected results are: 123 456 789 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.
Comment 1•21 years ago
|
||
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?
Reporter | ||
Comment 2•21 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 ConvertSpecialChars(); // get the resume text to pass into the preview dialog var strResume = new String(document.forms["ResumeFrm"].RESUME_INPUT.value); // 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, "height=490,width=780,resizable=yes,scrollbars=yes,titlebar=yes,left=5,top=50"); document.forms["PreviewFrm"].submit(); WinObj.focus(); } // 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, " "); // 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; }
Comment 3•21 years ago
|
||
> 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
Comment 4•20 years ago
|
||
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•20 years ago
|
||
contact info webmaster@webhire.com They should replace the following var reLineFeed = new RegExp("\r\n", "g"); with var reLineFeed = new RegExp("[\r\n]+", "g");
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 6•20 years ago
|
||
Conforming summary to TFM item 10 at http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new
Summary: carriage return stripped during form submission → webhire.com - carriage return stripped during form submission
Updated•10 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Updated•9 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•