Disabling a form field using javscript causes the field to be disabled even after a page refresh

RESOLVED INVALID

Status

()

Core
Document Navigation
RESOLVED INVALID
12 years ago
8 years ago

People

(Reporter: tommy, Unassigned)

Tracking

1.7 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
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

12 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

12 years ago
Component: General → History: Session
Product: Firefox → Core
QA Contact: general → history.session
Version: unspecified → 1.0 Branch

Comment 2

12 years ago
Reporter can you please attach your testcase in this bug itself.
Version: 1.0 Branch → 1.7 Branch
Yep, disabled state is persisted in session history quite purposefully.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID

Updated

9 years ago
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
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.
Duplicate of this bug: 502812
Duplicate of this bug: 468614
> 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.