Bug 142181 - forms cannot be accessed through implicit global variable definition
Summary: forms cannot be accessed through implicit global variable definition
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml ecma (show other bugs)
Version: 3.5
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Maksim Orlovich
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-25 15:27 UTC by Oded Arbel
Modified: 2008-04-20 20:45 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
testcase: cannot access form elements through implicitly defined global (581 bytes, text/html)
2007-02-25 15:28 UTC, Oded Arbel
Details
testcase: can't override the implcit undefined reference (648 bytes, text/html)
2007-02-25 15:50 UTC, Oded Arbel
Details
patch (2.75 KB, patch)
2007-02-25 21:42 UTC, Maksim Orlovich
Details
Automateable testcase (337 bytes, text/html)
2007-02-25 21:53 UTC, Maksim Orlovich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oded Arbel 2007-02-25 15:27:25 UTC
Version:           3.5.6 (using KDE 3.5.6, compiled sources)
Compiler:          Target: i586-mandriva-linux-gnu
OS:                Linux (i686) release 2.6.20-tmb-desktop-3mdvsmp

Konqueror implicitly defines globally scoped variables for each DOM element with an ID attributes (maybe for Internet Explorer compatibility? this isn't mandated by W3C DOM specifications). 

This implicit definition is not set for FORM elements. (see attached test case)
Comment 1 Oded Arbel 2007-02-25 15:28:15 UTC
Created attachment 19812 [details]
testcase: cannot access form elements through implicitly defined global
Comment 2 Oded Arbel 2007-02-25 15:50:05 UTC
Created attachment 19813 [details]
testcase: can't override the implcit undefined reference

The funny thing, is that I also can't override the implicit variable (that is
"undefined") - trying to set it to something (in this test case - to the
element itself) is futile and has no effect.
Comment 3 Maksim Orlovich 2007-02-25 20:12:24 UTC
Thanks for the testcase, but, uhm, there are no w3c specs on window, so the behavior is as good as a reverse-engineering/emulation we can do of IE and FFox based on bug reports... You're right that something funny is happening here, though, will take a look..

Comment 4 Maksim Orlovich 2007-02-25 21:42:04 UTC
Created attachment 19819 [details]
patch

This should fix it --- hasKey for HTMLDocument wasn't right for this case.. 
(And hence trunk shouldn't be affected). Not committing yet, since I can't
regtest this well atm..
Comment 5 Maksim Orlovich 2007-02-25 21:53:29 UTC
Created attachment 19820 [details]
Automateable testcase

A TC likely suitable for regression testing --- does not require human
interaction..
Comment 6 Oded Arbel 2007-02-25 23:26:27 UTC
Regarding comment #2 - this is an IE only emulation: Firefox/Gecko does not offer such a behavior.

Additionally, while there isn't currently a W3 specification for window object, the working draft for Window 1.0 ( http://www.w3.org/TR/Window ) does not mention such a compatibility mode. Not that I'm saying it shouldn't be implemented, but it still shouldn't break valid scripts.

Thanks for the patch, and I hope you can commit it to the 3.5 branch, as well as to the KDE 4 branch.
Comment 7 Maksim Orlovich 2007-05-10 17:21:50 UTC
Woops, still need to commit this...
Comment 8 Michael Leupold 2008-04-20 20:29:35 UTC
This is still reproducible in 3.5.9 but resolved in trunk r798768.
Comment 9 Maksim Orlovich 2008-04-20 20:45:04 UTC
Decided it's too invasive for 3.5.x.