125003 - wyciwyg garbage in location.href

Status: VERIFIED FIXED

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

Description

[bht237]

Build ID: 2001-02-11-08
top.location.href of a page that is loaded from the network contains a string
"wyciwig" in various string positions.
Attached testcase demonstrates one such scenario.

This brakes all sorts of JavaScript based navigation frameworks.

Comment 1

[bht237]

Attachment: the page that is loaded into the new window

Comment 2

[bht237]

Attachment: Starter page, opens new window

Comment 3

[bht237]

Attachment: the page that is loaded into the new window obsoletes 69023

Comment 4

[bht237]

Attachment: Starter page, opens new window obsoletes 69025

Comment 5

[bht237]

Hmm... It doesn't reproduce straight from the attachement.
Maybe the query string makes a difference.
On my local server I get something like:
http://localhost/wyciwyg/setter.htm
It's strange, sometimes the URL actually starts with wyciwyg.

Good luck!

Comment 6

[bht237]

I noticed there is a related bug 123140

Comment 7

[Boris Zbarsky [:bzbarsky]]

related to the point of being the same bug.  :)

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

Comment 8

[Radha on family leave (not reading bugmail)]

wyciwyg is a protocol that saves all data in a document.write() in the cache,
and restores it back when the user does a back/forward/go/reload on such pages.
It is not designed and does not break   all sorts of javascript based navigation
in framesets.  Prior to the implementation of wyciwyg, all session history
related navigations to such pages were broken. wyciwyg stands for "What you
cache is what you get". 

Comment 9

[bht237]

Radha, Thanks for the explanation.
I understand what you are saying. But I did not want to imply that wyciwyg per
se breaks anything.

What is breaking JavaScript-based navigation is the following:

If after the onLoad event of a document that comes from the network (not
document.write), its location.href is still the old wyciwyg pseudo URL of the
previous document that was in the same window/frame then things are going to break.

This is what the testcase attempts to demonstrate and nothing else.

Comment 10

[bht237]

This is not a duplicate of bug 123140. Please read my comments in both bugs.

This is about a data corruption that may be caused by a racing condition.

Comment 11

[Sivakiran Tummala]

i see this on linux too, build 2002-02-06-09 when a new window is opened.
Confirming bug

Comment 12

[Sivakiran Tummala]

setting priority to P4

Comment 13

[bht237]

Sivakiran, do you actually see the wyciwyg string as part of the alert in the
onload of the loaded file?

Comment 14

[Johnny Stenback (:jst)]

Over to radha for further investigation.

Comment 15

[Radha on family leave (not reading bugmail)]

I will download the testcases to my local machine and see the problem.  I will
be attending to my nsbeta1+ nominations first, before I can get to this. 

Comment 16

[Sivakiran Tummala]

i see as if it is a protocol.
wyciwyg://0/rest_of_the_url.

Comment 17

[bht237]

blocks bug 102341.
Added Brendan in cc list; maybe he can allocate additional resources.
My estimate is that a quick solution of this can avoid many headaches because
its consequences are erratic and difficult to analyse in some cases.

Comment 18

[Radha on family leave (not reading bugmail)]

I don't understand how this bug can block 102341. I read some of the latest
comments in that bug. Is there no other testcases to verify that bug 102341 is
indeed fixed? 

Comment 19

[bht237]

Radha,

in the Mozilla development environment, there is no dependency and you are of
course right.
There is indeed a testcase for that other bug and it _appears_ to be fixed.

However, _this_ bug blocks all of my Mozilla testing activities that are not
limited to testcases. A testcase pass is not the final proof that a bug is fixed.
That would assume there are no bugs in testcases.

Testcases are essential tools and I wouldn't submit a bug without one.
I make them for you not for me.

But I cannot make testcases without using Mozilla on real world sites (and that
is what I do most of the time).

With the Mozilla 1.0 target of this bug I am obviously getting to a stage where
I cannot detect new bugs any longer before this critical milestone.

I don't think that this is in anybody's interest.

I am afraid to say that the best proof for this logic is _this_ bug.
It is highly critical however there are no duplicates AFAIK, that means it is
ahead of other developments considering the uncertainties around bug 123140.

You should take advantage of me, really, and get this fixed asap and not
milestone dependent.

Comment 20

[Sivakiran Tummala]

there is a testcase on mozilla and internally on bubblegum.

http://bubblegum/ngdriver/suites/dom-html/hdoc027.html
http://mozilla.org/ngdriver/suites/dom-html/hdoc027.html

Comment 21

[Radha on family leave (not reading bugmail)]

wyciwtyg related. Need to be fixed for 1.0

Comment 22

[Radha on family leave (not reading bugmail)]

This will be fixed for 1.0 as targeted. 

Comment 23

[Judson Valeski]

we need to be sure we're not exposing wsciwyg URLs.

Comment 24

[Radha on family leave (not reading bugmail)]

I saved the testcase attachments is 69026 and 69027 in to my local machine. I
click on "Open new window". The new window comes up, shows the wyciwyg:// stuff
on the urlbar when "Please wait :)" is showing up on the screen. When the
onloadHandler kicks in and
http://bugzilla.mozilla.org/attachment.cgi?id=69026&action=view is loaded. The
alert pops up showing,
"http://bugzilla.mozilla.org/attachment.cgi?id=69026&action=view" in the  dialog. 

Beatrix, Am I missing something in reproducing this bug from my local machine?
You mentioned something like the testcase had to be modified. What should be
modified to see the bug?

What sivakiran is talking about is bug 123140. Once I change the code to strip
out wyciwyg from the urlbar, that will be fixed. 

Comment 25

[bht237]

Hi Radha,
Thanks for testing.
I repeated my local test and the error does not reproduce anymore.
Let me suggest to close this. It appears that bug 102341 blocks my testing at
this stage so the sooner that gets fixed the better.
I think the testcase in bug 102341 covers things fairly well.

Comment 26

[Radha on family leave (not reading bugmail)]

bht: 102341 is already fixed? You mean 125225 or 123140.

Comment 27

[Radha on family leave (not reading bugmail)]

 I can't reproduce this anymore. per bht's message above, i'm closing this out. 

Comment 28

[Sivakiran Tummala]

i can reproduce this on today's build 02-27-08 linux

Comment 29

[Radha on family leave (not reading bugmail)]

sivakiran: Can you explain what you can reproduce? wyciwyg:// appearing in hte
beginning or the  alert dialog in the test case attached shows a wyciwyg:// url
in the urlbar. 

Comment 30

[Sivakiran Tummala]

wyciwyg://0// appearing in the URL.

The testcase i used is
http://bubblegum/ngdriver/suites/dom-html/hdoc027.html

Comment 31

[Radha on family leave (not reading bugmail)]

That problem is addressed by bug 123140, which is still open and waiting for
reviews. 

Comment 32

[Radha on family leave (not reading bugmail)]

This is indeed WFM. 

Comment 33

[Sivakiran Tummala]

agree, based on comment http://bugzilla.mozilla.org/show_bug.cgi?id=123140#c11

Comment 34

[bht237]

Attachment: New testcase, always reproduces error. Zip file.

New tescase reproduces errors at all times. Tested with build 2002030804, 0.9.9
branch.
Note that this testcase succeeds with all browsers that I know of, including
Netscape 3.

Comment 35

[bht237]

I am re-opening this bug after a new testcase is available that reproduces the
error 100%.

Comment 36

[Pedro Lopes]

Isn't this bug the same as bug 125225 ? 
The last testcase posted seems to reflect exactly the behaviour reported in
125225 ("parent frame URL changes to
"wyciwyg://0//..." after using document.write in an iframe/subframe")

Comment 37

[bht237]

Pedro,
I first thought the same as you did.
But according to the description of bug 125225 ('URL bar changed to
"wyciwyg://0//...'), bug 125225 bug is only concerned with what is shown in the
URL bar and not with the corrupted data in window.location.href.

To back up this logic:
Bug 123140 was closed after the URL bar symptom was fixed although it has
testcases that still fail. From that I conclude that we need a bug for each of
the symptoms and one bug for the cause of the symptoms which is this bug.

Comment 38

[Radha on family leave (not reading bugmail)]

I'm working on a fix  for 125225 that will take care of location.href corruption
as well wyciwyg://showing up on urlbar for frame changes. 

Comment 39

[Radha on family leave (not reading bugmail)]

I ran the latest testcase here with my patch to bug 125225. I get the dialog
that says, "Success: URLs unchanged after docuemnt.write()" 

Comment 40

[bht237]

Thanks Radha.
This is extremely good news. I made the tescase as tough as I could and success
should mean success on all levels. You can increase the number of levels in the
js code beyond 6 frameset nesting levels.
I can't wait for the next build to test real world sites - and things should be
ok unless the testcase has a bug.

Comment 41

[Radha on family leave (not reading bugmail)]

I suspect that there is a small reporting error in the testcase. After loading
the testcase, if I press reload or go elsewhere and press back, the dialog says
failure and gives details. But in all the detail dialogs, the value it shows for
thisGoodURL, topResultURL and thisResultURL are all same and it is the top url
of the page. I don't know if that means real failure or success. I haven't
debugged further. 

Comment 42

[bht237]

Radha,
First thanks for this "extended" test. I think this is a separate issue and I am
surprised that Mozilla does not crash on it.
IMHO all browsers seem to have a problem with this extended test. If you don't
mind, here is my best guess, partly based on painful experience with Netscape 4
and most other major browsers:

If I start using the browser's history to navigate through framesets that
contain generated pages, then the following may happen:

If generated pages are fetched from the cache as generated content instead of
being regenerated exactly as at the first time, then the sequence in which they
are loaded into frames is (from experience) different.

Consequently, any JavaScript code, that depends on a predetermined sequence such
as hierarchical onload events, fails and causes unexpected results.

If you run this testcase from the cache, i.e. loading it via the Back button,
then you get these errors.
Netscape 4.7 crases this way. IE4 fails but does not crash.

You can possibly use this testcase to verify Mozilla behavior in an area where
other browser manufacturers have not gone yet.

I know that I had to write a JavaScript based history module to bybass these errors.

What I did not know and this is the first time I see this, is that such errors
are possible even when the file is loaded from the local file system.

Generally, the behavior of the testcase should not be different if loaded via
the back button.

Specifically, from what I can see in IE4, a parent onLoad event fires later than
a child onload event so that getGoodURL() returns an undefined goodURL value.
So far I cannot see that there is a bug in the testcase.

On the other hand the problem may be an onload event handler issue that has
nothing to do with this bug (top.location.href and wyciwyg).

Comment 43

[bht237]

Attachment: New tescase variation with extended reporting (zip file)

The new testcase includes reporting of top.goodURL on all levels. I cannot
verify against the latest patches because I cannot compile Mozilla.
But I guess it may explain failure when used with the back button.

Comment 44

[bht237]

Many thanks Radha,
I am very happy about the result after esting of some public internet sites.

Comment 45

[Sivakiran Tummala]

verified fixed, build 2002-03-18-09