"View Page Info" say that URI of all 4 window.open'ed windows are same, "wyciwyg://0/http://www.ops.dti.ne.jp/~muttley/test/dl-nest-test-1.html" in above test case. Therefore I think this bag is caused by bug 136633. However, this bug is resolved if different URI is assigned for each window.open'ed windows. For example, wyciwyg://1/http://www.ops.dti.ne.jp/~muttley/test/dl-nest-test-1.html , wyciwyg://2/http://www.ops.dti.ne.jp/~muttley/test/dl-nest-test-1.html .
I see similar slightly more confusing behavior with frames. In particular I get more than one different sources for viewing but some frames show the same content although they are clearly different. I am volunteering to test any mozilla versions after they are fixed against the testcase in this bug.
Those 4 windows should be getting 4 separate wyciwyg urls. This has nothing to do with view source. Over to Radha.
Assignee: doron → radha
Component: ViewSource → History: Session
OS: Windows 2000 → All
QA Contact: pmac → claudius
Hardware: PC → All
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.4beta
This bug clearly takes on the assumption nsHTMLDocument made that dynamic pages generated from a website will be off of an existing document instead of new ones. I will attach a patch shortly, but I need some good testing made before I can go for reviews. Beatrix, Do you have a test case for the comment #2?
Created attachment 117895 [details] [diff] [review] Patch to nsHTMLDocument.cpp This patch removes the assumption that dynamic pages generated off of a document will be displayed in the same window, thereby enabling each such page to have a unique url.
Attachment #117895 - Flags: review?(nisheeth)
Comment on attachment 117895 [details] [diff] [review] Patch to nsHTMLDocument.cpp r=nisheeth. Radha and I talked about this. We want to make sure that wyciwyg urls do not get stored anywhere permanent such that their lifetime spans across multiple browser sessions. Radha knows that wyciwyg document content is only stored in a memory cache which is good. She wasn't sure whether wyciwyg urls enter global history. If they do, then that is a bug which needs to be fixed. Regardless, this is a good fix! Thanks, Radha!
Attachment #117895 - Flags: review?(nisheeth) → review+
Just had a discussion with nisheeth regarding another problem with cache and wyciwyg urls. Shall open a separate bug for the same. wycicyg urls don't get into global history though.
Attachment #117895 - Flags: superreview?(jst)
Comment on attachment 117895 [details] [diff] [review] Patch to nsHTMLDocument.cpp sr=jst (Sorry for the delay here, this bugmail *just* arrived in my inbox, no idea where it was held up. Odd.)
Attachment #117895 - Flags: superreview?(jst) → superreview+
Attachment #117895 - Flags: approval1.4?
Attachment #117895 - Flags: approval1.4? → approval1.4+
Has this landed yet? I don't see anything in bonsai.
I'll bite. Checked in, trunk and 1.4 branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.4beta → mozilla1.4final
View source was displayed as expected on 2003052908-trunk/Win-Me. Thanks to developers.
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.