Closed
Bug 603863
Opened 15 years ago
Closed 15 years ago
div whose white-space is set as pre-wrap is not properly editable
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: tgvrs_santhosh, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(1 file)
|
1.85 MB,
application/octet-stream
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.63 Safari/534.3
Build Identifier: 4.0b6
In the below html code,
<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'
'http://www.w3.org/TR/html4/loose.dtd'>
<html>
<head>
<title>attribute identifiers test</title>
<script type="text/javascript">
function sampleFunc()
{
var divElem = document.getElementById("sampleDiv");
divElem.textContent = "Mozilla\n \n \nFirefox";
}
</script>
</head>
<body onload="sampleFunc()">
<div contenteditable="true" id="sampleDiv"
style="white-space:pre-wrap;"></div>
</body>
</html>
The textcontent of div has newline characters '\n'. As white-space is set as pre-wrap, it will respect those newline characters. Now, click on the second line such that the caret pos will be at the second character i.e second space. now, navigate to last character(i.e just before the newline character in the second line or just hit keyboard directionkey(->) two times) using keyboard direction key(->). Now, try to enter some character there, it will display in the thirdline.
Reproducible: Always
Steps to Reproduce:
In the below html code,
<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'
'http://www.w3.org/TR/html4/loose.dtd'>
<html>
<head>
<title>attribute identifiers test</title>
<script type="text/javascript">
function sampleFunc()
{
var divElem = document.getElementById("sampleDiv");
divElem.textContent = "Mozilla\n \n \nFirefox";
}
</script>
</head>
<body onload="sampleFunc()">
<div contenteditable="true" id="sampleDiv"
style="white-space:pre-wrap;"></div>
</body>
</html>
The textcontent of div has newline characters '\n'. As white-space is set as pre-wrap, it will respect those newline characters. Now, click on the second line such that the caret pos will be at the second character i.e second space. now, navigate to last character(i.e just before the newline character in the second line or just hit keyboard directionkey(->) two times) using keyboard direction key(->). Now, try to enter some character there, it will display in the thirdline.
Actual Results:
the character will be displayed in the newline.
Expected Results:
the character needs to be displayed in the same line.
|
||
Comment 1•15 years ago
|
||
Worksforme with a current trunk build.
Are you perhaps testing this in Firefox 3.6.10? Your bug report doesn't actually say what version you see the bug in....
|
|
Reporter | |
Comment 2•15 years ago
|
||
In Firefox4.0b6, if we press delete/backspace, then all the lines are getting deleted. This has been fixed in Firefox3.6.11. Now, this bug is even reproducible in 3.6.11. Attached is the webex recording of the bug. it requires webex 3.0 player to play.
|
||
Comment 3•15 years ago
|
||
Can you please go to about:buildconfig and copy and paste the entire contents of the page here?
|
|
Reporter | |
Comment 4•15 years ago
|
||
about:buildconfig
Source
Built from http://hg.mozilla.org/releases/mozilla-1.9.2/rev/053f07027a38
Build platform
target
i686-pc-mingw32
Build tools
Compiler Version Compiler flags
cl 14.00.50727.762 -TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
cl 14.00.50727.762 -GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
Configure arguments
--enable-application=browser --enable-update-channel=release --enable-update-packaging --enable-jemalloc --enable-official-branding --enable-tests
|
|
||
Updated•15 years ago
|
|
|
||
Comment 5•15 years ago
|
||
Hmm, I can confirm it on 3.6.11, but it works fine on trunk... Sounds like we need to backport a fix... I need to bisect to determine which fix.
|
|
||
Updated•15 years ago
|
|
|
||
Comment 6•15 years ago
|
||
Actually, this is not a regression. Firefox 3.5 also shows the same behavior. This is something that has been broken for a long time, and I highly suspect that this is fixed by one of the patches in bug 240933 (since before that time we didn't really support editing preformatted areas which have newline characters instead of BR nodes correctly). I'm going to mark this as FIXED as it's fixed on trunk, and I don't think that we need to backport a fix to 1.9.2 as it's not a highly visible bug, unless someone can show a website which is affected by this bug in practice.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 7•15 years ago
|
||
Hi Ehsan,
I'm not sure what you mean by trunk? do you mean 3.6 releases?
|
|
Reporter | |
Comment 8•15 years ago
|
||
Hi Ehsan,
I have tested in latest trunk build 4.0b8. It is working pretty fine. thanks for your support.
|
|
||
Comment 9•15 years ago
|
||
By trunk I mean mozilla-central, which is where the main development happens. You can grab an auto-updating nightly build from http://nightly.mozilla.org/ if you're interested in helping to test the trunk.
You need to log in
before you can comment on or make changes to this bug.
Description
•