130655 - top.location is being incorrectly changed when frames change

Status: VERIFIED DUPLICATE of bug 125225

(Core :: Networking, defect)

Description

[Paul Harrison]

I'm going to try and produce code that will reproduce the problem, but the
simpler ones I've tried aren't hacking it so...

I'm having trouble whereby the location property of the top window is getting
messed up when a sub-frame changes and has new stuff loaded into it. The
location box will reflect the URL of a subframe, and the location object will
return blanks for properties I need to access. This is a problem with 0.9.9 but
wasn't a problem with 0.9.8. Has anything major changed?

As soon as I'm able to create a reproducable example that doesn't involve giving
you billions of lines of JavaScript I'll post it.

Thanks,


Paul Harrison

Comment 1

[Paul Harrison]

Attachment: Sample HTML to reproduce the problem (caution: UGLY!)

This attachment is a zip file containing a sample frameset that exhibits the
bug. If you need more examples, I can ask my employer to give you access to the
product I work on. While the code above is somewhat ugly (sorry! We use a
somewhat odd third party database package that provides data in the form of
server-served client-side Javascript arrays. As a result, the entire product is
client side.) it does demonstrate the problem.

If you load entry.html into your browser, and ignore the warnings about
blank.html etc being missing, you'll get into a cut down version of our
newsflash facility. The location bar will show the URL of the visible frame at
the bottom of the screen (Bug!). Typing "javascript:
alert(top.location.protocol) in the location box will tell you it's "wyciwyg:".
(Bug!). Viewing "Page Source" will show you the source to the bottom visible
frame again.

Thanks for any help you can provide, please don't hesitate to call me for
further assistance. [phone] ex 210.

Comment 2

[Paul Harrison]

Before I forget, this has been confirmed on NT4 and Win98 on machines here. I
don't know about other platforms. Both were running build 2002031104.

Comment 3

[Boris Zbarsky [:bzbarsky]]

More fun wyciwyg stuff.  Radha, does your other patch fix this issue?

Comment 4

[Paul Harrison]

More information, after reading your "depends on" bugs this morning:

I tried to create a test case where the "bottom" frame did not include a
document.write..., and found that the bug "went away."

Going through the cases where the same bug afflicts other parts of our project,
in all cases during the lifetime of Javascript scripts called from a loaded
frame, if that javascript calls document.writeln then the URL of the page
containing the kicked off script will be moved to the location.

That mangled English is mangled for a reason: In many cases, the
document.writeln is applying to a frame that isn't the one that kicked off the
script, so it's NOT necessarily the URL of the frame whose document's writeln is
being invoked that gets put in the location bar, just the URL of the frame
which, directly or indirectly, called that writeln method.

Does that help?

I'll see if I can work on a new test case to help here,



Paul

Comment 5

[Paul Harrison]

Attachment: Test case - demonstrates criteria for changing location

This is a test case demonstrating the principle above. Notes:

1. On running, the location box will reflect the URL of the bottom visible
frame where the code that calls the code to write to the top frame's document
object is initiated.

2. There is no write to the lower visible frame's document object.

It's still a little ugly (I suspect most of the **** in there to do with our
project can be stripped out) but I don't want to remove that stuff in case I
end up *gag* fixing something ;-)

This pretty much obsoletes my old test case but Bugzilla will not let me mark
it as such.

Comment 6

[Radha on family leave (not reading bugmail)]

I think this is a dupe of 125225. I haven't tried the testcase attached here.
Once I do that, I will confirm the same. 

Comment 7

[Radha on family leave (not reading bugmail)]

Confirming. This is a dupe of bug 125225

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

Comment 8

[Sivakiran Tummala]

verified dupe

Comment 9

[Paul Harrison]

Summary was garbled by last change.

I hope the person who garbledthe summary wasn't using Mozilla ;-)

Comment 10

[Frank Nestel]

:mcmanus, how can a 15 years old duplicate dom related bug block pipelinining?

Comment 11

[Dragana Damjanovic [:dragana]]

(In reply to Frank Nestel from comment #10)
> :mcmanus, how can a 15 years old duplicate dom related bug block
> pipelinining?

a typo, i.e. 1340655