Closed
Bug 59909
Opened 25 years ago
Closed 22 years ago
Value doesn't redraw in <INPUT type=text> if it has exact width of element
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: c, Assigned: kinmoz)
References
Details
(Keywords: helpwanted, testcase)
Attachments
(1 file)
|
740 bytes,
text/html
|
Details |
If the value of an <INPUT type=text> has exactly the width of the content area
it won't be redrawn any more if the value is changed with JS/DOM.
Testcase:
<HTML>
<STYLE>
#input1 { width: 17px; font: 12px Courier }
#input2 { width: 18px; font: 12px Courier }
#input3 { width: 19px; font: 12px Courier }
#inputX { font: 12px Courier }
</STYLE>
<SCRIPT>
function Set() {
var date= new Date();
document.getElementById( "input1" ).value= date.getSeconds();
document.getElementById( "input2" ).value= date.getSeconds();
document.getElementById( "input3" ).value= date.getSeconds();
document.getElementById( "inputX" ).value= document.getElementById( "input2"
).value;
}
</SCRIPT>
<BODY onload="setInterval( Set, 1000 );">
<FORM>
<INPUT id=input1 type=text>
<INPUT id=input2 type=text>
<INPUT id=input3 type=text>
<INPUT id=inputX type=text>
</FORM>
</HTML>
Note that the value is still set, but will never be shown again, even if the
width changes (seconds 0..9 in the testcase).
Maybe you'll have to adjust the exact width of the <INPUT> elements to observe
this behavior.
NS 6.0.0.2000110801, Win NT and trunk 2000-10-30-06.
|
Reporter | |
Comment 1•25 years ago
|
||
|
||
Comment 2•25 years ago
|
||
I see this in linux trunk build 2000111106.
Confirming. What a weird bug...
OS -> All
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
|
||
Comment 4•25 years ago
|
||
assigning to kin for review
Assignee: beppe → kin
Target Milestone: --- → mozilla0.9
|
|
||
Comment 5•25 years ago
|
||
moving to future, we will address this one when we can
|
|
Reporter | |
Comment 7•24 years ago
|
||
I can reproduce this without JS if I paste text into such a form.
Both the old and the new text must have exactly the width of the content area.
A related bug is bug 66756.
Same cause as bug 50578 - there is an optimization path in the C++ side that is
having side-effects when an internal state in the code ends up a constant value.
I will nevertheless leave this one open.
|
|
Reporter | |
Comment 10•24 years ago
|
||
A similar thing happens with table backgrounds: bug 91443.
|
|
||
Comment 11•24 years ago
|
||
*** Bug 99607 has been marked as a duplicate of this bug. ***
|
|
||
Comment 12•24 years ago
|
||
*** Bug 116207 has been marked as a duplicate of this bug. ***
|
||
Comment 13•22 years ago
|
||
WFM with build #2003051108 on Win98. Andreas, can you still reproduce this bug
with a recent Mozilla build?
|
||
Comment 14•22 years ago
|
||
WORKSFORME, 2003-05-28-08 trunk Linux
You need to log in
before you can comment on or make changes to this bug.
Description
•