If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

default values of hidden fields are not taken as null or undefined

VERIFIED INVALID

Status

()

Core
DOM: Core & HTML
P3
normal
VERIFIED INVALID
19 years ago
18 years ago

People

(Reporter: Stephen P. Morse, Assigned: vidur (gone))

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE] brad@basesystem.com)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
Following content prints out the before message but not the after message.  If
the line:

          "<INPUT TYPE=HIDDEN NAME=goneS>" +

is replaced with:

          "<INPUT TYPE=HIDDEN NAME=goneS value=\"\">" +

it works fine.  In 4.x browser this works fine (after "dump" is changed to
"alert" of course).  So I'm not sure if it is a javascript error or a
compatibility error.

<HTML>
<HEAD>
  <SCRIPT>
    button_frame = 0;

    function loadFrames(){
      top.frames[button_frame].document.open();
      top.frames[button_frame].document.write(
        "<FORM name=buttons>" +
          "<INPUT type=BUTTON value=OK onclick=parent.Save()>" +
          "<INPUT TYPE=HIDDEN NAME=goneS>" +
        "</FORM>"
      );
      top.frames[button_frame].document.close();
    }

    function Save(){
      var goneS = top.frames[button_frame].document.buttons.goneS;
dump("before result=");
      var result = goneS.value;
dump("after result =");
    }

  </SCRIPT>
</HEAD>
<FRAMESET ROWS = 25,25 onLoad=loadFrames()>
  <FRAME SRC=about:blank>
  <FRAME SRC=about:blank>
</FRAMESET>

<NOFRAMES>
  <BODY> <P> </BODY>
</NOFRAMES>
</HTML>

Updated

19 years ago
Assignee: norris → vidur
Component: JavaScript → DOM Level 0

Updated

19 years ago
QA Contact: 4590 → 4015

Updated

18 years ago
Status: NEW → ASSIGNED
Whiteboard: [MAKINGTEST] brad@basesystem.com

Comment 1

18 years ago
Created attachment 1353 [details]
This is the simplest possible test-case for bug 6918

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
Summary: default values of hidden fields are not taken as null → default values of hidden fields are not taken as null or undefined
Whiteboard: [MAKINGTEST] brad@basesystem.com → [TESTCASE] brad@basesystem.com

Comment 2

18 years ago
I simplified this bug to the following html:

<HTML>
<HEAD>
  <SCRIPT>
    function writeInfo() {
      document.open();
      document.write(
        "<FORM name=TestForm>" +
          "<INPUT TYPE=HIDDEN NAME=HiddenVar>" +
        "</FORM>");
      document.close();
      var HiddenVar = document.TestForm.HiddenVar;
      var result = HiddenVar.value;
      alert("result = "+result);
      alert("Correct answer should be result=undefined");
    }
  </SCRIPT>
</HEAD>
<BODY onload="writeInfo()">
</BODY>
</HTML>

A description of this bug:
This html uses javascript to write the html for a form into a document.  This
form has a single hidden input that is not initialized with a value.  The
"expectation" is that this value should default to null or undefined (what the
correct behavior actually should be is discussed below).  However, Mozilla
reports that the hidden value has a blank value, rather than a null or undefined
value.

A discussion of this bug:
I am not sure that this is really a bug.  I tested the script under Netscape
4.61 and it also reported a blank value for the hidden input.  Internet Explorer
5.0 reported the same behavior.

If this error is in how javascript handles the DOM, since we are writing the
form html into the document rather than pre-defining it, then if I just type the
html right into the document the hidden input should be initialized correctly,
right?  I created the following test-case to test this theory:

<HTML>
  <HEAD>
    <SCRIPT>
      function printInfo() {
        var HiddenVar = document.TestForm.HiddenVar;
        var result = HiddenVar.value;
        alert("result = "+result);
        alert("Correct answer should be result=undefined");
      }
    </SCRIPT>
  </HEAD>
  <BODY onLoad="printInfo()">
    <FORM name=TestForm>
      <INPUT TYPE=HIDDEN NAME=HiddenVar>
    </FORM>
  </BODY>
</HTML>

The hidden form input is now directly put into the html rather than being
created through javascript.  When run in mozilla this second test-case _also_
reports that the hidden input is not initialized to null or undefined but rather
to a "blank" (an empty string). Netscape 4.61 reports the same thing, as does IE
5.0.

I have checked the W3C and have not been able to find out what the default value
for an hidden input value that has no starting value should be.  It should
probably be undefined, since the ECMAScript standard says that anything that has
not been initialized is undefined.

Vidur, please comment on what the correct behavior of this "bug" should be.  To
me it does not appear to be a bug.

Comment 3

18 years ago
There is a possibility that I have misunderstood this bug.  I have emailed the
reporter to get another description.

Comment 4

18 years ago
Created attachment 1354 [details]
Non-javascript html that has the form

Comment 5

18 years ago
The environment and details under which I tested the bug:
Mozilla build 1999081911
Windows 95 4.00.950 B
Has IE 5.00.2014.0216 intalled
Dell Windows 95 PC
Pentium Pro
63.0MB RAM
(Reporter)

Comment 6

18 years ago
You can leave the resolution as invalid if you like, but the real resolution
should be works-for-me.  I just tried it and it is now working fine in 5.0 so it
apparently got fixed with some changes that were made since the bug was
reported back in May.

Just for clarification, I was not complaining about the fact that it printed out
a blank value rather than a null value.  Rather it wasn't printing out any value
-- the first printout occured but there was absolutely no second printout if
goneS was not initialized.  Today there is a second printout so the bug has been
fixed.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 7

18 years ago
verified invalid (or really "worksforme" as morse suggested)
You need to log in before you can comment on or make changes to this bug.