Closed
Bug 293733
Opened 20 years ago
Closed 20 years ago
Disabling a form field using javscript causes the field to be disabled even after a page refresh
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: tommy, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
This example page illustrates the bug:
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//NO'
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>JS -Test</title>
</head>
<body>
<input type="text" name="test" id="test"/><br/><br/>
<a href="#" onclick="foo()">foo</a>
<script type="text/javascript">
function foo() {
document.getElementById('test').disabled = true;
}
</script>
</body>
</html>
When you click on the link, the input field is disabled, as expected, but after
a refresh (ctrl-r), the field is still disabled.
Reproducible: Always
Steps to Reproduce:
1. Load the HTML page
2. Click on the link
3. Refresh the page
Actual Results:
Input field is still disabled
Expected Results:
Input field should not be disabled.
|
||
Comment 1•20 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050418 Firefox/1.0.3
For the future, you will find that most regulars at Bugzilla prefer test
cases to be attached rather than pasted in.
Whilst I haven't checked your case, I believe that what you see is the intended
behaviour.
What happens if you do a full refresh, shift-ctrl-r?
This report is probably not a bug - BY DESIGN.
|
||
Updated•20 years ago
|
Component: General → History: Session
Product: Firefox → Core
QA Contact: general → history.session
Version: unspecified → 1.0 Branch
|
||
Comment 2•20 years ago
|
||
Reporter can you please attach your testcase in this bug itself.
Version: 1.0 Branch → 1.7 Branch
|
||
Comment 3•20 years ago
|
||
Yep, disabled state is persisted in session history quite purposefully.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
|
||
Comment 4•15 years ago
|
||
Boris,
why is disabled state of form elements persisted? I've read your comments in bug #306616 but you didn't explain the reasoning for this behaviour.
Please see bug #468614 for a testcase regarding <select> and bug #502812.
|
|
||
Comment 7•15 years ago
|
||
> why is disabled state of form elements persisted?
I (or someone else) would have to go back and read the original bugs on that... You're welcome to if you want to, of course. It's about rock bottom low priority for me.
I wouldn't be opposed to changing the behavior if someone comes up with a consistent description of what form state restoration _should_ act like. I'm opposed to random back-and-forth tweaking, though.
You need to log in
before you can comment on or make changes to this bug.
Description
•