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.
I'm pretty sure this is already reported
over to AP Apps
Timeless, *this* is your bug.
See also bug 60437. Also see bug 8589. I assume there are a plethora of improvement bugs to html editing.
Also see bug 63892.
i'm still stuck by the question in the status or the equivalent question, of how do i send a string to view-source...
*** 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. ***
Generated source bookmarklet: http://www.squarefree.com/bookmarklets/webdevel.html#generated_source
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)
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 firstname.lastname@example.org as qa contact. to find all bugspam pertaining to this, set your search string to "ItsSharkeysNight".
*** 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. ***
The ability to serialize the dom exists. Therefore, it shouldn't be (too) hard to create generated source. See bug 128655
*** 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.
*** Bug 175156 has been marked as a duplicate of this bug. ***
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...
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. ;)
*** Bug 178634 has been marked as a duplicate of this bug. ***
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.
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.
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.
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. ***
*** Bug 239190 has been marked as a duplicate of this bug. ***
> and it's not possible to see the generated content in view source Select-All, and then view selection source.
*** 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. ***
SeaMonkey trunk is now using toolkit viewsource.