Closed Bug 125225 Opened 23 years ago Closed 23 years ago

URL bar changed to "wyciwyg://0//..." after using document.write in an iframe

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: amla70, Assigned: radha)

References

Details

(Keywords: testcase, topembed+)

Attachments

(5 files, 5 obsolete files)

Inner frame to be used later
234 bytes, text/html
Details
Testcase, just click on the link, wait 5 seconds and the url will change
639 bytes, text/html
Details
Testcase 3. Single file, convenient
2.83 KB, text/html
Details
Testcase 3 Start here obsoletes above
2.95 KB, text/html
Details
patch to docshell v1.2
1.14 KB, patch
rpotts
: superreview+
asa
: approval+
Details | Diff | Splinter Review
As the summary says, the URL bar changes after using document.write in an iframe. According to http://bugzilla.mozilla.org/show_bug.cgi?id=123140#c32 this behaviour should be submited as a new bug. I'll attach right now the files to prove the problem. (Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8+) Gecko/20020212)
Content of the file: <html><head> <title>inner frame</title> </head> <body> Wait 5 seconds... <script type="text/javascript"> window.setTimeout("document.open();document.write('Changed.');document.close();", 5000); </script> </body></html>
Keywords: testcase
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
We have to take care of this for 1.0, as wyciwyg is not a standard protocol. ADT,EDT, please give it a +. Also see bug 123140 and bug 125003 for more details.
Keywords: nsbeta1, topembed
Keywords: nsbeta1, topembed → nsbeta1+, topembed+
This problem seems to happen only with iframes. On regular frameset pages, this bug doesn't show up. investigating ....
Moving testcase from bug 123140. This page eventually gets loaded by the one that follows.
Just click on the link to see the problem. _top's href gets set to subframe's href when subframe loads a wyciwyg; url. This page loads the one above.
Please update the description of the bug to "parent frame URL changes to "wyciwyg://0//..." after using document.write in an iframe/subframe" Just reflecting Radha's view in bug 123140 #84 that this bug addresses that "a doc.write in a subframe affects the url of the _top". The primary issue is that the URL data (location.href) is changed. The secondary issue is that the incorrect URL data is (correctly) reflected in the view (URL bar). The secondary issue might go away without further attention if the primary issue is solved first. I will provide supporting additional test cases when they become available and also on request when Radha needs them.
Attached patch patch to docshell (obsolete) — — Splinter Review
The proposed patch makes sure that wyciwyg urls are added only once to session history.
Comment on attachment 72655 [details] [diff] [review] patch to docshell hey radha, i don't understand how 'addWyciwygToHistory' can be static... it seems wrong to share this flag among ALL docshells... -- rick
Testcase 3 gives better coverage and is more convenient. Second tescase 72459 won't work when clicked on (application/octet-stream).
Re Testcase 3: You must download this file and change line 57 to load the filename as what you have saved it e.g. index.htm. There is no way that I know in advance the URL of the attachment.
Is this really networking?
Attachment #72458 - Attachment is obsolete: true
Attachment #72459 - Attachment is obsolete: true
Attachment #72655 - Attachment is obsolete: true
Attachment #73171 - Attachment is obsolete: true
Blocks: 130557
Blocks: 130655
Attachment #73984 - Attachment is obsolete: true
*** Bug 130655 has been marked as a duplicate of this bug. ***
Comment on attachment 74133 [details] [diff] [review] patch to docshell v1.2 r=adamlock, but I have a question about the aProgress to webProgress comparison. Is it possible for both to be nsnull and therefore for the test to succeed when it shouldn't?
Comment on attachment 74133 [details] [diff] [review] patch to docshell v1.2 sr=rpotts@netscape.com mLoadCookie should *never* be null. So, i think the comparison will work (even if aProgress == nsnull)...
Attachment #74133 - Flags: superreview+
Hi Radha, It looks there is great progress on this one. Just let me know when and where I can download a build with your patches and I will do some serious real world site testing for you (BTW my testcases are all derived from real web site code, sometimes a painful process).
Comment on attachment 74133 [details] [diff] [review] patch to docshell v1.2 a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74133 - Flags: approval+
This got fixed last week.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
rahda: You did not respond to my question about the component correctness. Is this a networking (necko) bug?
No. It isn't.
Component: Networking → History: Session
QA Contact: benc → claudius
vrfy'd fixed using 2003.02.19 comm trunk on linux rh8.0 and win2k.
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: