81889 - frame displays document based on initial src attribute after resize [frame]

Status: VERIFIED DUPLICATE of bug 48422

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

Description

[Hans Aikema]

From Bugzilla Helper:
BuildID:    2001051804

When resizing a frame in javascript by updating the frameset's cols attribute 
the document that was initially in the frame (as specified in the frameset 
document by its src attribute) is loaded instead of the document that was 
visible in the frame at the moment of resizing.
Updating the frame's src attribute manually in the onLoad event resolves this 
problem, but in my opinion this update is the Mozilla's responsibility instead 
of the webmaster's.
The page at http://home.zonnet.nl/speedsk8/mozilla/framebug.html refers to two 
examples, one of the actual problem and one with the work-around active.

Reproducible: Always
Steps to Reproduce:
1. Load http://home.zonnet.nl/speedsk8/mozilla/framebug1-1.html
2. Play with hide/unhide as you like
3. Go to the second page (link in frameset)
4. click on hide/unhide

Actual Results:  After step 4 the page frame contains the initial document 
(http://home.zonnet.nl/speedsk8/mozilla/framebug1-2.html)

Expected Results:  After step 4 the page frame contains the document you changed 
to (http://home.zonnet.nl/speedsk8/mozilla/framebug1-3.html)

Comment 1

[Prashant Desale]

Updating QA contact to Shivakiran Tummala.

Comment 2

[Fabian Guisset]

Confirmed with build 2001060308 win2k. The document refered in the src attribute
of the frame is loaded instead of the current document.
Marking NEW.

Comment 3

[Johnny Stenback (:jst)]

Over to pollmann.

Comment 4

[Kevin McCluskey (gone)]

Bulk reassigning form bugs to Alex

Comment 5

[alex.dent]

happens on mac release 0.9.5 (build 2001101117) as well.

does anybody have a workaround hack? alexandru, do you have an estimate when you
will have some time to look at this bug?

Comment 6

[alex.dent]

oops, too fast. this bug is probably a dupe of bug 69347, which is probably a
dupe of bug 48422, and most probably also related to bug 63980, which should be
marked as a dupe of bug 48422 or bug 69347.

with all this confusion, there is only one solution - fix it ;-)

btw, i'm not allowed to mark this bug as a duplicate.

Comment 7

[Alexandru Savulov]

i added the dependencies be cause the bugs are not really dups so we don't want
to lose them.

setting milestone

Comment 8

[Sivakiran Tummala]

nominating bug for nsbeta1

Comment 9

[Kevin McCluskey (gone)]

nsbeta1-

*** This bug has been marked as a duplicate of 48422 ***

Comment 10

[Sivakiran Tummala]

verified dupe