190006 - HTMLFrameElement: fails *every* testcase [broken testcases]

Status: RESOLVED FIXED

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

Description

[Francesco De Francesco]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 2

[Johan Buret]

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 :-)

Comment 3

[Johan Buret]

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

Comment 4

[Fabian Guisset]

I fixed the broken testcases. Marking FIXED.