Bug produced in both Chrome and Safari on Windows 7. 1) Go to: http://prettydiff.com/?s=http://prettydiff.com/prettydiff.js&m=minify 2) Verify contents of the textarea match the value of the value property in the dom using the console: document.getElementById("minifyoutput").value; If the values differ the bug is valid as the DOM is property updated, but such update is not reflected in the textarea element on the page.
(In reply to comment #0) > Bug produced in both Chrome and Safari on Windows 7. What version of Chrome and Safari? > 1) Go to: http://prettydiff.com/?s=http://prettydiff.com/prettydiff.js&m=minify > 2) Verify contents of the textarea match the value of the value property in the dom using the console: > document.getElementById("minifyoutput").value; > > If the values differ the bug is valid as the DOM is property updated, but such update is not reflected in the textarea element on the page. I couldn't find differences. Can you explain what part is differ concretely?
I have verified it on Chrome 20.0.1132.47. I have Safari on a different computer, so I will specify Safari version number later. I downloaded the latest version from Apple two days ago. More specific steps to reproduce: 1) Go to: http://prettydiff.com/?s=http://prettydiff.com/prettydiff.js&m=minify 2) Wait for the page to fully load. There is some JavaScript and XHR that this URI will execute in the onload event. 3a) Look into the textarea labeled "Minify output". Perform CTRL+A (select all) and CTRL+C (copy to clipboard) and then paste the copied text to your favorite editor. Scroll to the very end of this text and notice how this text ends. 3b) An alternate option is to simply look into the textarea "Minify output" and scroll to the end of the text. This option will be faster, but is also frustrating. It is easy to scroll at the way down. Unfortunately there is a fair amount of horizontal scrolling for text that is not present. You must scroll to the end of the text and not to the end of the scrollbar. 4) In the browser console perform: document.getElementById("minifyoutput").value; 5) Scroll the extreme end of the text provided from step 4. 6) Does the text from step 3 match the text from step 5? I can produce the bug following these steps every time even on different computers. This error has occurred for me in the past on Windows XP, but the computers I have been testing recently are all Windows7. These values must be identical because they are values obtained from the same form element. If the values are different then it suggests the entirety of the text is being updated to the value property of the textarea in the DOM, but not to the textarea element in the UI. As I mentioned in step 3b I am getting excessive horizontal scrolling that could suggest the horizontal scrollbar is updated to the length of the text as reported from the DOM even if that text is not fully present in the textarea. I suspect the error could be related to any text flow presentation supplied to the textarea. To my knowledge there are only two forms of such presentation accepted: 1) The white-space CSS property 2) The wrap HTML attribute
Thanks, I confirmed the problem. We have the line length limitation in WebKit. This problem occurs with any elements.
That begs some questions: 1) Should scrolling be shortened to accommodate the length of text that is accepted opposed to the length of text that is expected? 2) Should the value in the DOM be sliced in order to match the value accepted by the element in the UI so as to maintain uniform concurrency between the element and its value in the DOM? 3) Should the user be warned when their data is not fully accepted? 4) If this is accepted behavior shouldn't this behavior be equally reproducible in other elements, such as input type text or div elements with overflow scroll CSS property? I cannot reproduce the behavior in these other conditions. From the perspective of a user the current behavior looks like an unexpected irregular operation that occurs in a given edge case without notification. This looks like a bug unless there is means to inform the user that the behavior is expected and is operating uniformly by all access means. If it is not a bug then it presents an access condition disparity where data is available in one case but the equal and identical data is not available in a different access means. At that point it may become an accessibility violation.
This appears to be a prior documented phenomenon: https://bugs.webkit.org/show_bug.cgi?id=51168#c5
Created attachment 152141 [details] Repro with <div>
(In reply to comment #6) > Created an attachment (id=152141) [details] > Repro with <div> I might have failed to create a repro. It makes a blank in the long line though it has the correct line-end. Anyway, this issue is about long physical line. We can avoid this issue by wrapping lines.
*** This bug has been marked as a duplicate of bug 29636 ***