View Source doesn't show the source generated by JavaScript

RESOLVED FIXED in mozilla1.4final



Document Navigation
16 years ago
10 years ago


(Reporter: Koike Kazuhiko, Assigned: Radha on family leave (not reading bugmail))




Firefox Tracking Flags

(Not tracked)




(1 attachment)



16 years ago
If JavaScript code generates multiple window, View Source of the each window
shows the source of last window.

"View Page Info" say that URI of all 4'ed windows are same,
"wyciwyg://0/" 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'ed windows.
For example,
 wyciwyg://1/ ,
 wyciwyg://2/ .

Comment 2

16 years ago
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
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 6

16 years ago
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+

Comment 9

15 years ago
Has this landed yet?  I don't see anything in bonsai.
Whiteboard: landed1.4?

Comment 10

15 years ago
I'll bite. Checked in, trunk and 1.4 branch.
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.4beta → mozilla1.4final


15 years ago
Keywords: fixed1.4
Whiteboard: landed1.4?
View source was displayed as expected on 2003052908-trunk/Win-Me.
Thanks to developers.


10 years ago
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.