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.
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?
> 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
contact info email@example.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
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
URL is obsolete. [closeme]
Status: ASSIGNED → RESOLVED
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.