User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.2.1) Gecko/20021130 MultiZilla/v1.1.18 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.2.1) Gecko/20021130 on every test page linked to the given URL my build fails the frame test. it seems the actual results are 'shifted down' of an element (the first actual is 'undefined', the next two are equal to the first two in the right column). to have an idea, see http://mozilla.org/quality/ngdriver/suites/dom-html/hfrm003.html Reproducible: Always Steps to Reproduce: 1. point mozilla to the URL 2. click on any link on the right 3. notice the red rows :( Actual Results: frames should be correctly identified Expected Results: frame #1 is not correctly detected, the next are switched by one http://mozilla.org/quality/ngdriver/suites/dom-html/hfrm009.html returns a 'Not Found' (404?) page: I think for the same reason
> it seems the actual results are 'shifted down' Yes, they are. The testcase is buggy; at some point someone put in these getElementsByTagName calls and the indices into the nodelist are off-by-one.
Assignee: jst → desale
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: HTMLFrameElement: fails *every* testcase → HTMLFrameElement: fails *every* testcase [broken testcases]
Indeed, somebody who has the right to modify the proposed testcases should replace "getElementsByTagName('*')" in function htmlFrameElementMarginHeight by "getElementsByTagName('frame')" in $local_path/res/hfrm003a.html . this testcase behaves just as it is told to do :-)
*** Bug 210743 has been marked as a duplicate of this bug. ***
I fixed the broken testcases. Marking FIXED.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.