242557 - If I have a hidden field and it is accessed in a event of a tag <a href ...> it fails

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Juan Carlos]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421

for example I have the next variable 
<form name="form1" method="post" action="main.jsp">
<input name="hago" type="hidden" value="">
if I do the next item variable
<input type="button" name="Button"  value="<<" class="inputButton"
onClick="hago.value='<<'; submit();">

and its work fine but if i have the next
<a href="#" onClick="hago.value='load'; submit();"> << </a>

this do not work and i see the javascript console and report hago is undefined

Reproducible: Always
Steps to Reproduce:
1.declare a input hidden
2.uses this input hidden in an event of a tag <a href>
3.

Actual Results:  
the page does not do nothing the  java script console shows that the field is
undefined

Expected Results:  
perform then event onclick

Comment 1

[Boris Zbarsky [:bzbarsky]]

Nothing to do with form submission.  jst, this sounds like that scope chain
thing that we removed... did we hack in something for inputs?

Comment 2

[Johnny Stenback (:jst)]

Hmm, yeah... Form controls have their form as their JS parent, other nodes have
the document as their JS parent, thus form controls will only appear in the
scope of forms or form controls, not links. I wonder if IE special cases links
here, or if anything in a form gets the form as its JS parent?

We could make the code that finds the JS parent look up the parent chain for an
HTML form element, and if it finds one, use it. But that could hurt performance
if we do it across the board... Thoughts?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Juan, if you replace the <a> with a <div> in IE (and leave the onclick handler
on the div), what happens?

Comment 4

[Juan Carlos]

In IE it works equals with the tag <div> as the tag <a>, I update the test page 
in the url there is the test with <a> with <div> and with <input type button>

Comment 5

[Boris Zbarsky [:bzbarsky]]

What is window.xjc in IE?

Comment 6

[Juan Carlos]

xjc is the name of the hidden field, if you see the source code there is, the 
form is named "jc" and the input hidden is named "xjc"

Comment 7

[Boris Zbarsky [:bzbarsky]]

Yes, I know it's the name.  That doesn't answer my question.  What does
"window.xjc" evaluate to in IE on that document, especially when evaluated from
script that is not a child of the form?

Comment 8

[Boris Zbarsky [:bzbarsky]]

*** Bug 247745 has been marked as a duplicate of this bug. ***

Comment 9

[Boris Zbarsky [:bzbarsky]]

So how much would it really hurt to look for a form?  We used to do it, no? 
Before bug 147058 landed?

Comment 10

[Johnny Stenback (:jst)]

Shouldn't be too bad if we do it only for links...

Comment 11

[Boris Zbarsky [:bzbarsky]]

I'd say let's just do links.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Well, doing just links won't help bug 253267 and bug 253091.

I'm marking this confirmed; whatever's going on we're breaking a sites that used
to work and that work with IE.....

Comment 13

[Brendan Eich [:brendan]]

In this DOM level 0 territory, it seems to me we have to do what IE did. 
Netscape 4 is too old, and it lacked onclick for divs and such.

How hard can it be?

/be

Comment 14

[Boris Zbarsky [:bzbarsky]]

Brendan, as I understand it bug 147058 was fixed to give us IE compat on a
different set of testcases....

So apparently, it's hard. Step one is to figure out what it is IE is doing.

Comment 15

[Mats Palmgren (inactive)]

*** Bug 254418 has been marked as a duplicate of this bug. ***

Comment 16

[Boris Zbarsky [:bzbarsky]]

This bug and its dependancies should be retested now that bug 256932 has been
fixed.  Chances are, a lot of the testcases suddenly work now...

Comment 17

[Bob Firth]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041024

I don't see any improvements for any of the dependant bugs. :(

Comment 18

[Boris Zbarsky [:bzbarsky]]

Indeed....  See bug 264247 comment 6.  In short, the fix for bug 256932 doesn't
apply to inputs.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Could we decide something here one way or another and maybe implement it in 1.9?

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The most logical thing (and therefor easiest to understand) is probably to make
everything inside a form use the form as the parent. This way peoples stuff
won't break just because they change a tagname from <a> to <div>.

Of course, there is the issue of performance. Walking up the parent chain is
pretty cheap these days though since nsIContent::GetParent is non-virtual and
inline.

Comment 21

[Phil Ringnalda (:philor)]

*** Bug 312523 has been marked as a duplicate of this bug. ***

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This isn't really blocking, but it'd be nice to fix. Jst thinks the perf hit wouldn't be too bad, but the problem might be that none of our tests would see it. Though dHTML might catch it.

Comment 23

[Hixie (not reading bugmail)]

window.xjc in IE is null. Looks like IE really is just putting the <form> element into the scope chain of anything with a <form> descendant. That's annoying.

Comment 24

[Paul Silaghi, QA [:pauly]]

Dropping qawanted based on comments 17, 18.

Comment 25

[Michelle Funches - QA]

Cannot reproduce
Version 	50.0a1
Build ID 	20160715063552
User Agent 	Mozilla/5.0 (Windows NT 5.1; rv:50.0) Gecko/20100101 Firefox/50.0