Last Comment Bug 293733 - Disabling a form field using javscript causes the field to be disabled even after a page refresh
: Disabling a form field using javscript causes the field to be disabled even a...
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: 1.7 Branch
: x86 Windows XP
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
: 468614 502812 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-11 02:12 PDT by tommy
Modified: 2009-08-31 05:20 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image tommy 2005-05-11 02:12:26 PDT
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 User image Ben Fowler 2005-05-11 02:44:17 PDT
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.
Comment 2 User image Justin Wood (:Callek) [away until Feb 27] 2005-05-13 21:07:04 PDT
Reporter can you please attach your testcase in this bug itself.
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2005-06-16 21:07:29 PDT
Yep, disabled state is persisted in session history quite purposefully.
Comment 4 User image Daniel Kabs, reporting bugs since 2002 2009-08-31 02:52:49 PDT
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 5 User image Boris Zbarsky [:bz] (still a bit busy) 2009-08-31 05:19:20 PDT
*** Bug 502812 has been marked as a duplicate of this bug. ***
Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2009-08-31 05:19:24 PDT
*** Bug 468614 has been marked as a duplicate of this bug. ***
Comment 7 User image Boris Zbarsky [:bz] (still a bit busy) 2009-08-31 05:20:42 PDT
> 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.

Note You need to log in before you can comment on or make changes to this bug.