Open Bug 60426 Opened 24 years ago Updated 2 years ago

Allow users to choose between generated and source html in view-source

Categories

(Toolkit :: View Source, enhancement)

Product:
Toolkit
Component:
View Source
Platform:
All
Other
Type:
enhancement

Tracking

()

People

(Reporter: netdragon, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted) 

There would be a submenu for View Source. One choice would be Original - giving
you the ability to view the source as it was when it was downloaded. The other
choice would be Translated. This would show the source as it currently is (ie if
there were document.write's etc).
This would rock.  The ability to see generated content in view-source needs to 
be implemented anyway so scripters can debug about:blank stuff, but I can't 
find the bug.  (The about:blank problem was mentioned in bug 6119.)

This feature would go well with bug 12111, which suggests several additional 
modes for view source.

See also bug 49721, which wants to be able to view the generated source for the 
selected part of the page.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Allow two versions of source view → [rfe] Allow users to choose between generated and source html in view-source
I'm pretty sure this is already reported
over to AP Apps
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Timeless, *this* is your bug.

ok.
Assignee: don → timeless
Whiteboard: how do i embed \n into data:text/plain,<somewhereinhere>
Target Milestone: --- → mozilla0.9
See also bug 60437. Also see bug 8589. I assume there are a plethora of
improvement bugs to html editing.
Whiteboard: how do i embed \n into data:text/plain,<somewhereinhere>
Whiteboard: how do i embed \n into data:text/plain,<somewhereinhere>
Also see bug 63892.
No longer blocks: 28809
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla0.9.1
i'm still stuck by the question in the status or the equivalent question, of 
how do i send a string to view-source...
Keywords: helpwanted
Target Milestone: mozilla0.9.1 → mozilla1.0
I just tried typing in the URL bar:

javascript:window.open("data:text/html,<pre>a\nb</pre>")

and it did the right thing... (though the URL bar is only showing the URL up to
the \n

For more fun try:

javascript:window.open("view-source:data:text/html,<pre>a\nb</pre>")

The thing is, can we depend on this behavior staying this way?
*** Bug 81172 has been marked as a duplicate of this bug. ***
*** Bug 86222 has been marked as a duplicate of this bug. ***
*** Bug 93652 has been marked as a duplicate of this bug. ***
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
I was buggin' along in bugzilla and I realized a good use for this. Making a
javascript to create a certain html output and then freezing the by saving the
generated content and removing the javascript to make it look like you
painstakingly went through and added each output.

You can write a page like this:

<html>
<body>
TEST LINKS OF A BUNCH OF NUMBERS<br>
<script type="text/css">


var i;
for (i=0;i<1000;i++)
{
  if (i!=0) document.write(" | ");
  document.write("<a href='"+i+".html'>"+i+"</a>");
}

</script>
</body>
</html>
Boris: isn't that a bug that the \n isn't shown in the URL bar?
mass moving open bugs pertaining to view source to pmac@netscape.com as qa contact.

to find all bugspam pertaining to this, set your search string to
"ItsSharkeysNight".
QA Contact: sairuh → pmac
*** Bug 69912 has been marked as a duplicate of this bug. ***
there is a rough sketch on how this could be done with XSLT in bug 69912
*** Bug 125672 has been marked as a duplicate of this bug. ***
Depends on: 128655
No longer depends on: 128655
The ability to serialize the dom exists. Therefore, it shouldn't be (too) hard
to create generated source. See bug 128655
in addition to comment 13, a bookmarklet (javascript bookmark) to view
tag-colored generated source can be found here in bug 55583#220:
<URL:http://bugzilla.mozilla.org/show_bug.cgi?id=55583#c220>

the javascript tag coloring in that link is not very good, so this shouldn't be
considered a solution, just a temporary fix.
*** Bug 143233 has been marked as a duplicate of this bug. ***
If this is implemented, generated-and-prettified source-view should
be the default for accessibility reasons (as a lynx-like interface).
I doubt the advanced users will complain too much for having to
select the original source-view for debugging, etc..
As a note, the backend for this exists already:

Ctrl-A, right-click, "View Selection Source" will give you the generated source
of the whole doc.
Summary: [rfe] Allow users to choose between generated and source html in view-source → [RFE] Allow users to choose between generated and source html in view-source
Summary: [RFE] Allow users to choose between generated and source html in view-source → Allow users to choose between generated and source html in view-source
*** Bug 175156 has been marked as a duplicate of this bug. ***
As a general comment and especially re Comment #25 :

I would prefer that this view-source mode includes all code not only the
user-selectable part (Ctrl-A, right-click, "View Selection Source" displays only
a subset of the document).

The reason for this is simple:

We need a means to validate _any_ document as a whole, whether it is only partly
or fully generated in the browser. AFAIK Netscape 4 does this perfectly and we
have been relying on this.

Without such a tool, how would one be able to commercially (without dirty tricks
and JavaScript hacks) design web standard compliant client-generated content?

The next obvious thing that is going to come up is view source of generated
framesets which are, AFAIK, not accessible to such a user selection. How do you
do that?
Keywords: 4xp
View Selection Source will show you serialized DOM so it is _always_ valid. 
Hence using it to validate anything is pointless.
Comment #28 is interesting.

I understand this bug is about _generated_ _source_. Please correct me if I am
wrong. So if I have a bug in my generated source I need a means of feedback to
get rid of this bug.

How can I do that in Mozilla?

Netscape 4 returns the code as document.write() writes it. Ideal for
examination/validation and correction if required.
> How can I do that in Mozilla?

You cannot, and doing it mozilla would require incredible rearchitecting of
either the entire DOM or the cache.  That information is simply not stored
anywhere and storing it would incur a footprint cost that the DOM owner was not
willing to pay, last I checked.

Netscape 4 cached the document in its post-document-write form (as we do for
documents created entirely with document.write()).  This is why it was able to
retrieve the "source".  It's only possible to do this if you don't have to
support the DOM (eg in NS4 the <script> tags are simply gone from the document.
 Since there is no way to access them via DOM, there's no way to tell this.  In
Mozilla that would be very obvious).

So there is some confusion here about what "generated source" is.  To some
people it's "Take the HTML, run all the scripts, remove them from the source,
replace them with the content they wrote out".  To others it's "What source
would I need to write to generate a document equivalent to this one".
Thanks Boris for the clarification.

So you are saying that this bug defines "view-source" as
Format 1) "What source would I need to write to generate a document equivalent
to this one"

and _not_

Format 2) "Take the HTML, run all the scripts, remove them from the source,
replace them with the content they wrote out".

AFAIK Netscape 4 only removes those inline scripts that write to the doc not
scripts in the head section.

Now how does Mozilla cache hybrid documents such as:
<BODY>
document.write(parent.getSomeContent());
</BODY>
?
With hybrid I mean that they are files loaded over the network that include any
number of document.write() scripts.

If I could get the complete document in Format 2) I would be very happy.
I am just trying to find a way out of this dilemma that is format 1) is actually
fairly useless for an application designer.
I'm not saying anything about how this bug defines it.... because as far as I
can tell both definitions are present in various places in this bug.

> AFAIK Netscape 4

Inside <body>:

<script>
var foo = 1;
document.write(foo);
</script>

The script will be removed.  But the "1" can be used by later scripts in the
document!  Oh, and scripts in <head> can also document.write()... the point is,
all those script nodes need to be present in the DOM.

> Now how does Mozilla cache hybrid documents such as:

I'm not sure what this question is asking... we cache the original source and
when the document is loaded we parse it, run all the scripts, etc...
>> Now how does Mozilla cache hybrid documents such as:

>I'm not sure what this question is asking... we cache the original source and
>when the document is loaded we parse it, run all the scripts, etc...

Thanks. So I understand a hybrid document is not cached as DOM the same as a
100% generated document. Meaning if it is taken out of the cache then it is
parsed again. In other words this opens the opportunity to process it
differently in view-source mode which is good news.

I am writing this in response to the concern:

"You cannot, and doing it mozilla would require incredible rearchitecting of
either the entire DOM or the cache.  That information is simply not stored
anywhere and storing it would incur a footprint cost that the DOM owner was not
willing to pay, last I checked."

So I am speculating that a hybrid document does not require this footprint cost
because nothing needs to be done beforehand to prepare such a document for later
view-source presentation. It might just be a matter of taking it out of the
cache and re-process it differently. I mean we don't have to store the generated
source in the cache in any way such as "wyciwig".
Of course one would have to care about the JavaScript context such as parent,
top etc. because document.write() might get content from there.
Yes... and in general rerunning scripts for view-source is a somewhat risky
proposition security-wise... But yes, that could maybe be done.  It would
involve modifying the parser and script loader a good amount...
That sounds very promising, very high value for developers.

We could get by, by prototyping with data-pulling skeletons such as:

<!--Begin of file -->
<SCRIPT>
document.write(otherWindow.getSomeContent());
</SCRIPT>
<!--End of file -->

or, until the cross window security issues are resolved:

<!--Begin of file (extremely simplified, for this we would not need view source
obviously)-->
<HEAD>
<SCRIPT>
var someContent = "<BODY>SomeContent</BODY>";
</SCRIPT>
</HEAD>

<SCRIPT>
document.write(someContent);
</SCRIPT>
<!--End of file -->

Then we could examine the code with view-source and run it through our
validation processes.

When prototyping is finished we can move this to production safely as:

otherWindow.document.open();
otherWindow.document.write(getSomeContent());
otherWindow.document.close();

and then we don't need to care about Format 2) not being available to us in 100%
generated content.

I think this method would have tremendous commercial value.

Please correct my if I am wrong but I do not know of any alternative to this
except using Netscape 4 which is a very risky preposition.
You could use a server-side scripting environment to test...

Note that the changes required to do this in Mozilla would be pretty widespread
and risky, as I said....

Don't mind me, though.  I'm just offering technical advice.  ;)
For those who might be interested and aren't already aware of it:
view-source is broken in the context of multiple windows/frames.
For me this means I can't use view-source.

View Source doesn't show the source generated by JavaScript
    bug 172251

Hope this helps, maybe priority-wise.
*** Bug 178634 has been marked as a duplicate of this bug. ***
Mozilla could do it like this: when such a ViewSource option for a certain 
page is demanded, then it could get the page the way Netscape 4 does it: 
download it (save it like Netscape 4 saves pages in its cache), then process the 
page and then show generated source. I guess that would require some changes to 
the cache.

And here are all the important arguments:

Boris Zbarsky:
> You cannot, and doing it mozilla would require incredible rearchitecting of
> either the entire DOM or the cache. That information is simply not stored
> anywhere and storing it would incur a footprint cost that the DOM owner was 
> not willing to pay, last I checked.
-- I didn't understand the last part of the sentence or most of the programming 
vocabulary. How would either of these comments (by Zbarsky & NZ guy) be 
reflected in English?

NZ guy:
> Thanks. So I understand a hybrid document is not cached as DOM the same as a
> 100% generated document. Meaning if it is taken out of the cache then it is
> parsed again. In other words this opens the opportunity to process it
> differently in view-source mode which is good news.

What is important to most web developers (who happen to have extensive use of 
JavaScript):
> So if I have a bug in my generated source I need a means of feedback to
> get rid of this bug.

and
> We need a means to validate _any_ document as a whole, whether it is only 
> partly or fully generated in the browser.
-- This means: We need to see all of the document in ViewSource where it shows 
HTML written by JavaScript (through document.write or through a function the 
like).

Another option would be for the JavaScript debugger to do the same (to show HTML 
instead of JavaScript) or something similar, but show more at the place of an 
error than it does now.

So if Boris Zbarsky's comment (whatever he means there with risk and security) 
prevails, then we just would have to stick with Netscape 4 (4.8 and the like).
I suggest WONTFIXing "view-source of charstream as seen by the parser".

Doing that for all documents will cause Mozilla to use considerably more memory,
so that's a nogo.
Doing it only on demand, that is, if somebody called this version of view-source,
would require reevaluating the scripts, and re-apply all the side effects. I 
expect to cheer if they loose all their frame navigation just due to a 
view-source.

Mart, I suggest rethinking your publishing structure. But if you really want to
rely on document.write in situations complicated enough that they fail and want
the source as the parser sees it in Mozilla to verify that, I guess the best 
thing you can do is create your own build, and modify the parser to feed all
it's input to some file, or so.
> How would either of these comments

1)  Mozilla does not store the "document with all document.write() evaluated"
    anywhere, unlike NS4
2)  Doing so would be prohibitively expensive in two or more of the following:
    cache space, memory, performance

I second Axel's suggestion that moving to a model that does not rely on
document.write is much more fruitful than trying to debug code that uses it.
Everything has been said here. The facts are on the table.
View-source has become slightly ambiguous since Mozilla.

1) Viewing written source as in NN4 is no longer supported. This is the subject
of this bug and there cannot be any confusion otherwise this bug should not exist.
This is the source combined from static HTML and from HTML written by
document.write().

2) View source generated retrospectively by the DOM has only academic or
educational value. It is definitely different from what document.write() puts out.

The issue here is that a solution is required especially for architectures that
are true client-server. In a client-server environment, the dynamic content is
kept isolated from the presentation. In other words the dynamic portion of the
content contains no HTML.

For this architecture it is a natural requirement that dynamic HTML pages are in
fact templates that pull their content from JavaScript data.
Such template documents are what I called previously "hybrid" because they
contain multiple scripts with document.write().

It happens that only for those template type of pages, which would be easiest to
support by Mozilla without cacheing (refer to comment #33), are causing a
serious problem for developers.

In other words:

A page that only exists as 100% document.write() output could for design/QA e.g.
HTML validation purposes be written to an alternate source and be inspected by
the designer. Problem solved.

A hybrid/template page that exists as a URL on the network, either server
generated or stored as a file, cannot, without heavy manipulation, be inspected
for correctness.

This is a shame because it makes Mozilla useless as a true client-server
application platform.
Unless of course one completely abandons document.write() and uses other dom
methods do generate content. Funny enough that would at the time of writing
require separate solutions for different browsers, which is not a good ide where
Mozilla/Netscape 7 has close to 0% market share. In 10 years time maybe
document.write() is no longer used. But that's not subject of this bug; Mozilla
needs to be fixed for what is required now.

Mozilla should take this opportunity, get over the pain it takes to implement this.

Alteratively one could of course write this off, mark for oneself Mozilla as a
whole WONTFIX and get on with the job using Netscape 4 as the only alternative.
> that pull their content from JavaScript data.

Why javascript data?  What you have described so far sounds to me like it would
be much more cleanly and efficiently (in terms of server cycles, client cycles,
and latency) dealt with via SSI or a similar server-side mechanism...

People keep bringing up NS4.  Repeat after me.  NS4 did not have a DOM.  This
made doing this much easier in NS4.  Show me a single DOM-enabled browser that
can do this properly!

I'm not saying it's not possible.  I'm saying that I don't believe that the
hundreds of developer hours needed to do this are worthwhile.  It would be a
neat feature to have, but really not worth the amount of work that would have to
be put in (we're talking months of work, most likely).  And until you find
someone who _does_ believe it (as you apparently do) and is willing to volunteer
that much of their time to do it (which you apparently are not) this bug is not
very likely to move forward.... (one more thing to keep firmly in mind -- this
is a volunteer effort; people work on things that they want to work on; if
something is wanted by enough people, surely one of those people will be found
who is willing to work on it. See the "helpwanted" keyword.).  That said, if
someone _is_ willing to work on this and needs pointers/advice/someone to bounce
ideas off of, feel free to mail me.
bht: do you really need Mozilla (the default build) to support original,
generated, and hybrid view-source?  Or would you be ok with a special version of
Mozilla, or a tool like DOM inspector?

Everyone: the reason this worked easiliy in 4.x (easily, modulo nasty bugs to do
with the spaghetti control flow between old netlib and layout) was because all
document.write did was loop back through the parser, via the same (or a proxy,
don't ask) netlib stream that the original tags came in on.  So interposing a
"tee(1) [unix program]" caching stream convertor was relatively straightforward,
and guaranteed to capture all the tags (original and generated).  The wysiwyg:
URL was invented to name the resulting generated document.

We have wyciwyg: in Mozilla now, does that not help?  Hmm, I just read bug
172251 and wonder if that's the bug to focus on.  Is the problem that even if we
fix that bug, we don't cache original source, and can't reconstruct it from the
dom content model?

Anyway, expanding the disk cache to include more generated and original source
is not obviously a memory buster.  So I don't agree with bz's comment #41 point
(2), esp. as document.write may be uncommon enough that most pages (top100?)
won't suffer any performance penalty.  Without studying the performance of a
prototype, I wouldn't want to say how badly a cache convertor would be, if it
could be interposed.  It'd want to write the cache file asynchronously, for
sure, so long as the cache subsystem could coherently hit the buffers being written.

If this is too much work for the default-built code paths, then maybe someone
can cobble up a helper tool.  I don't see a need to WONTFIX, although the bug's
current summary may need to change.

Timeless, are you serious about hacking on this?

/be
Mid-air with bz: want to reiterate that I'm not proposing the default-built code
paths worry about this bug, but it does seem to me valid to want something like
DreamWeaver or a similar authoring/debugging tool to do the right thing.  That's
the direction to morph this bug, if there is enough interest.

"Two way tools" or verbatim roundtrip source recovery or whatever you want to
call it is a required virtue in such power tools.

/be
Thanks Brendan and Boris for your comments.

Brendan, NN4 for _me_ is definitely a power IDE and I doubt that this has come
about by coincidence i.e. I think the Netscape developers were smart to get it
there.

I cut and paste between frame URLs in page info (frame info not available in Moz
yet) and external editor macros that translate these into local file names.

And I use the old debugger applet with the nice object inspector which is - well
- worth some money but it comes free.

That proves the concept for me that one can build a fairly complete environment
with external tools and maybe Mozilla can support such a basic open approach as
well.

Unfortunately view-source is pivotal because the browser is the only point of
reference and any server side workarounds simply don't cut it as they introduce
new mismatches, uncertainties etc. I am talking about QA here, rock solid
development support - not being interested in viewing pretty-printed source code
for whatever reason. Give me a hidden wyciwig URL that I have to calculate or
something crude - it doesn't matter to me how difficult it is.

If there was a tool that I had to download separately or a hidden preference
that would be fine. Whatever it is, it should tackle the most difficult task of
viewing the source of combined static HTML and inline document.write().

Sorry to repeat this but this is really the issue where all known methods fail
and its solution from what Boris and you seem to agree would be easiest to
implement. A kind of a sweet spot that I would hate to see WONTFIXed.

That functionality is needed to develop forward looking high performance
applications not the basic 99% sites. I seem to think that document.write() is
not the ultimate solution since we have the DOM but it is an indispensible tool
to bridge the gap between browser generations in use today.
Does the DOM WG's serialization stuff help us here?  As a save-as option, or --
better -- a DOM-inspector-like web-developer add-on, it might be sufficient.
shaver, see comment 28 and on.  Oh, and the W3C serialization stuff is for XML
only.  At least with XML you know the source is well-formed, so there
serializing the DOM is a fairly accurate representation of the source.
bht/NZ:
> I cut and paste between frame URLs in page info (frame info not available in 
> Moz yet) and external editor macros that translate these into local file 
> names.

Frame info is readily available in Mozilla. In a frame, request the context 
menu with in the frame area, then This Frame > View Frame Info; you can also do
this when you request the context menu (within the frame) and type h and i to
view frame info.

> That functionality is needed to develop forward looking high performance
> applications not the basic 99% sites. I seem to think that document.write() is
> not the ultimate solution since we have the DOM but it is an indispensible 
> tool to bridge the gap between browser generations in use today.

Using document.write and browser identification to 'bridge the gap between
browser generations' is important, but this kind of Viewsource for Mozilla is
needed, as Netscape 4 shows only the source that only applies to it. For example, 

if Netscape4, then write this;
else write that

and Viewsource shows only the code written for N4. That is why to have N4's
current viewsource functionality or the way it presents itself is very
important, as I need to evaluate code written for Moz. JavaScript errors in Moz
also seem to show less than in N4 (IE seems to be worst of all) and the
JavaScript Debugger (or Venkman) is of no use to me. And fonts in its
(Venkman's) sections are too large. /-Mart.
http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsParser.cpp#2594
seems to have this for debug builds.
Mart, call this function in a debug build and be done.

Reiterating, I think that Mat's kind of view-source should not be in default 
builds. It's very useful for him, and it seems that he might have a good chance
to get to the information he wants in debug builds.
Pretty sure we should not worry about a UI for this, or a real interface.
Mart I agree with you. I should have said that itentifying frames is not
"complete" in Mozilla because we can't get at the source/URL of a framesetter
within a frameset and a frame that has 0 width and height.
But I have read somewhere in bugzilla that a frame hierarchy view as in NN4 is
planned.
i was more interested in generated (dom) source than generated (inline) source.
doron says that the evang sidebar can do that already. as for generated inline,
i'm not bloating our parser for it.
Assignee: timeless → doron
Status: ASSIGNED → NEW
Component: XP Apps → ViewSource
Whiteboard: how do i embed \n into data:text/plain,<somewhereinhere>
Go to http://mozilla-evangelism.bclary.com/sidebars/, and install the Milla
Source Generator sidebar.  
*** Bug 201959 has been marked as a duplicate of this bug. ***
retargeting
Target Milestone: mozilla1.0.1 → Future
*** Bug 239190 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Implementing this bug would be useful for us at Eyewonder because our
interactive ads (such as expandable ads) placed on portal sites actively modify
the pages' DOM from javascript files, and it's not possible to see the generated
content in view source for debugging purposes (such as having javascript
inserting HTML comments in DOM). Note that DOM Inspector does show the changes,
but that's not very handy for quick looks. We're therefore forced to use
javascript alerts only.

What would work well is to be able to click (or double-click) on lines that
include other content such as ( <javascript src="foo.js" ) and <link> tags and
the external file would expand in place of that line. Clicking again would close it.

See also bug 120457 - "Save As" should optionally allow to save generated
content of a page

> and it's not possible to see the generated content in view source 

Select-All, and then view selection source.
I realized that comment #57 was not exactly relevant to this bug, but instead
bug 17612. Expanding <link>ed to and <script src="foo.js"> files is not showing
generated content, and even when it's javascript, the document.write causes
things to be placed in the DOM under the script element. Therefore, ignore
comment #57 with respect to this bug. I moved the comment to bug 17612, comment #19.

Boris: Thanks for the tip about "view selection source" to show generated
content, that'll be very useful.
*** Bug 313743 has been marked as a duplicate of this bug. ***
*** Bug 323290 has been marked as a duplicate of this bug. ***
*** Bug 335237 has been marked as a duplicate of this bug. ***
Assignee: doronr → mrbkap
Priority: P3 → --
QA Contact: pmac → doronr
Target Milestone: Future → ---
Assignee: mrbkap → nobody
QA Contact: doronr → view-source
Blocks: 276769
SeaMonkey trunk is now using toolkit viewsource.
Product: SeaMonkey → Toolkit
QA Contact: view-source → view.source
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.