Closed Bug 74862 Opened 24 years ago Closed 15 years ago

Ability to save highlighted source in view-source

Categories

(Core Graveyard :: View Source, enhancement)

Product:
Core Graveyard
Component:
View Source
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: bischoff, Unassigned)

References

(
URL
)

Details

Attachments

(4 files)

This is the resulting file, going through your process.
36.95 KB, text/html
Details
very raw-around-the-edges patch
2.56 KB, patch
Details | Diff | Splinter Review
Cleaned-up patch with complete UI included
6.18 KB, patch
Details | Diff | Splinter Review
patch that disables the menuitem as needed
6.57 KB, patch
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) BuildID: 2001040504 Mozilla makes some pretty syntax hilighting in View Source, and it would be great if the HTML code used to create such coloring were available (that is, the auto-generated HTML *in* the View Source window). This would be handy, for instance, when writing HTML or JavaScript tutorials for the web, as the author's code could be converted-to-colorized quite easily in this manner. Reproducible: Always Steps to Reproduce: 1. Right click on any url 2. Choose "View Page Source" 3. In the View Source window, right-click again 4. Notice that there is no context menu, which of course doesn't include "View Source" Actual Results: View Source window has no context menu, and this doesn't include a " View Source" option. Expected Results: "View Source" should be an option within View Source. This could be related to bug 39389.
Windows 2000,build 2001040420 You can select the source or part of the source en copy it to the clipboard (Ctrl-c or ctrl-insert). When pasting in an editor that understands the HTML clipboard format it is pasted as highlighted source. Tested this on Word 2000 and it works. So this would probably be a duplicate or a depend on bug 63026.
Could you give me an example of such an editor on Win2000? Also, just to make sure we're talking about the same thing, I'll elaborate on the feature request. If I choose View Source on this very page, I get a window with the source code, with syntax coloring. Among other things, the <html> and <head> tags are purple, strings are blue, and "nbsp" is orange. If I were to choose View Source *on* the "View Source" window, I'd like to see html code such as the following: &lt;<font color="purple">html</font>&gt;&lt;<font color="purple">head</font>&gt; [...] &lt;<font color="purple">body</font> <b>BGCOLOR</b>=<font color="blue">"#FFFFFF"</font> <b>TEXT</b>=<font color="blue">"#000000"</font> (And so on..) Does that make sense? That is, I'd like to see the *actual HTML* that makes the coloring and syntax hilighting within the View Source window.
I understand what you mean. I tried this on Frontpage. It seems the Mozilla editor also supports this, pasting the highlighted source in Composer set to 'normal view' mode , it is pasted including the highlighting code. Switch to'<html> source' to see the source. Copy the highlighted source <td VALIGN="TOP"> in Composer gives: <pre style="font-family: -moz-fixed; font-weight: normal; color: black; padding- top: 4px; margin-left: 4px; ">&lt;<span style="color: purple; font-weight: bold; ">td<span style="color: black; font-weight: bold; "> VALIGN</span>=<span style="color: blue; font-weight: normal; ">"TOP"</span></span>&gt;</pre>
I went through the process that you describe with Composer (see attachement). However, it doesn't quite look the same, especially in the line-breaks department. So, nonetheless, your method is an almost-workaround (and gives a very close approximation of what I'd like to see in View-Source-of-View-Source). However, since there's still the discrepancy, I'd like to see this feature fully implemented.
confirming rfe. ->bill?
Assignee: ben → law
Status: UNCONFIRMED → NEW
Ever confirmed: true
I would think that's merely composer shreading the html and not a flaw in this feature which seems to have already worked by the type you reported it.
doron, is it easy to make it so we can save the content of the view source window? Would that fulfill this RFE?
I believe when my menu path lands, that using the "edit page" command will launch composer with the sourcecode with highligthing. I'll check it out later. As for a viewsource window for the viewsource window, should be easy.
Actually... a view source of view source may not be so easy. This is how view source works. A webshell has two modes. In normal mode it just shows the document. In View Source mode it shows the source. So for view source all we do is take a webshell, put it in View Source mode and load the URI of the page we are viewing source for. The textual representation of the view source window is not stored anywhere -- the document is constructed directly in the parser, so it just exists as a parse tree...
right, was not thinking when I wrote that. question is, how usefull would this feature actually be?
As a professional Web Engineeer, this would be highly useful to me. As I often write HTML and/or JavaScript tutorials for my co-workers (and others), I frequently have to show example source code in a webpage. If I were able to use View-Source-of-View-Source, it would greatly ease my task of color coding my code (and changing ">" to "&gt;", etc).
this is a very nice feature to have whenever menus and context menus for view source window will be implemented, maybe just put 2 different types of save in them? File -> Save as text File -> Save as HTML this bug depends on bug 39389 and bug 63026
Depends on: 39389, 63026
IMO the default "save as" option in View Source (if there is a "save as" option) should be to save the original source.
As long as we're adding dependencies... Adding dependency on bug 66334 -- until that arch change is in, doing this is a waste of effort. Once that's in we can figure out how to do this properly.
Depends on: 66334
Have a look at the teaser bug 78619. Got the menu item there. Ah, only if it would work... ;o) This issue also raises a question of infinite regression of viewsource. That is: ViewSource -> ViewSource of ViewSource -> ViewSource of ViewSource of ViewSource -> and so on.
Bug 78619 will most likely get fixed by disabling the "view source" options inside view source, is my guess. Without some major rearchitecting infinite recursion will not happen. That rearchitecting would take place in the parser. The last rewrite of view source restored the ability to dump the source of view source to a file as it's being rendered on the screen. This is currently inside a debug #ifdef, but the thought was that we could change that code slightly and allow a "Save as colored source" menu option to view source. Then you could open the resulting HTML in your favorite text editor. Would that work? In either case, this is parser work. Over to parser.
Assignee: law → harishd
Component: XP Apps: GUI Features → Parser
QA Contact: sairuh → bsharma
Yeah, as long as there's some way to capture the source that's generated within View-Source, then that's a plus :). As for the "infinite recursion", why is that a bad thing? It's not like it's uncontrolled infinite recursion -- the user has to hit "View Source" each time to progress along the path of View-Source-of-View-Source-of-View-Source.
I'm not saying it's a bad thing. I am just saying that the entire way we do view source would need a complete rewrite from scratch with a totally different approach of some sort in order to support that sort of recursion. Unless we can come up with a good reason to do it (coolness factor is not good enough, imo) it's probably not worth the effort. Taking this bug to implement the save-to-file approach. Alex, let me know if I misunderstood you and that would not do what you're asking for. Doron, you want to handle the menu side of this?
Assignee: harishd → bzbarsky
OS: Windows 2000 → All
Priority: -- → P3
Target Milestone: --- → mozilla0.9.2
Status: NEW → ASSIGNED
Boris: As a Web Engineer, I often write HTML and JavaScript tutorials, both for my co-workers and others. So, I often need to include example code in these web based tutorials -- and, it'd be really convenient if I could capture Mozilla's output instead of having to color-code my code on my own. So, either solution (View-Source-of-View-Source-of-View-Source or Save-View-Source) would suit my needs. Though the former does have a certain coolness factor to it ;), I can understand if that's too extensive.
I have this pretty much working. But to do it right I have to grab the stylesheet from the DOM. That works if I cheat, but depends on bug 79818 if I do it right. So adding dependency.
Depends on: 79818
OK. Attaching a patch. This is just the backend function -- the menuitem/key shortcut/whatever still need to be added to call it. It has one other issue -- "haha" is not a good title for the filepicker in this case. We want to decide on something nice in a stringbundle and then grab it from there, most likely.
Reviews please? doron? blake?
Keywords: mozilla0.9.2, patch, review
Notice that the patch adds a file (xpfe/browser/resources/locale/en-US/viewSource.properties). So if you have trouble applying that may be why.
tree has closed for 0.9.2. Pushing out to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Soo... it's been 3 weeks. Anyone care to actually review that last patch? :)
Keywords: mozilla0.9.2 → mozilla0.9.3
patch looks great, just one thing - what if syntax highlighting is turned off? Perhaps disable the context menuitem if that pref is set off?
r=doron
I am not familiar with the implementation of the View Source window, but it occurs to me that the result document could be dynamically generated via XSLT. This would leverage existing code, and allow for further application of the stylesheet to generated views. Not only that, it would permit user-defined view-source style by manipulation of the associated style sheet. This is probably too high risk/low reward for an RFE, but it seems like the Right Thing.
Resummarizing to make it clear what the bug is about at the moment. Talked to blake, who isn't sure this is a good idea to have in the UI at all. mpt? What do you think? I can provide a screenshot if you'd like.
Summary: [RFE] View-Source of View-Source → [RFE] Ability to save highlighted source in view-source
pushing out pending mpt's comments.
Target Milestone: mozilla0.9.3 → mozilla0.9.5
Ooh, this is truly bizarre. `File' > `Save As ...' from the View Source window should do exactly the same thing as `File' > `Save As ...' from the browser window -- that is, save the original HTML, not some entitied-and-colored-up-the-wazoo HTML rendering of the source. If it didn't save the original HTML, people would start filing that as a bug. (If `View Source' was available for the View Source window at all, that would be a bug too. `View Source' should change to `View Page' in a View Source window, to do the opposite of what `View Source' does in a browser window.) That the coloring is done using HTML formatting is an implementation detail which should be completely transparent to the user. Hmmm ... file format transparent to the user ... That reminds me of something. What? Oh, yes. The system clipboard! So ... When text is copied from the View Source window and pasted into an app which understands colored text (such as Composer, or MS Word), the coloring should get pasted too. As Timeless said, any bugs in that copy/paste process should be filed, but this bug looks very much like a wontfix.
Matthew's comments made me think of this in a new way. What concerns me about this feature is that it will force Mozilla to downgrade a Strict XHTML page. That is, assuming that the output of this function is *just* (X)HTML, the color information has to be in the generated (X)HTML, not in a stylesheet. IIRC, this means the (X)HTML will no longer validate against the Strict DTD, whereas the source document would have. While this could be handled by generating both (X)HTML and the stylesheet, it makes it a little dirtier at the same time. This also raises the question of the "appropriate" representation of the color information. Should it be HTML, Transitional XHTML, Strict XHTML? While a decision may not be necessary for cut-and-paste because of flavors, it may be elsewhere. If I had to choose, I'd pick Strict XHTML, but that gives the aforementioned two document problem. Other "solutions" suffer similar pitfalls, either forcing a downgrade somewhere, or relegating Mozilla to generating primitive HTML, which also seems dirty.
Just to address some comments: > When text is copied from the View Source window and pasted into an app which > understands colored text (such as Composer, or MS Word), the coloring should > get pasted too. Ooh.... Fun. Is there a cross-platform way of representing color information in the clipboard? The old setup we had (where color was done with style attributes on spans) would at least keep color when copied as HTML. The new setup (with color done as classes and a stylesheet) will _not_ keep the colors when copied as HTML, of course. The wonders of separating content and presentation (and I'm not being facetious, I mean that). One can of course add a stylesheet to the resulting document to highlight the code -- the class names will still be there. > `File' > `Save As ...' from the View Source window should do exactly the same > thing as `File' > `Save As ...' from the browser window With my patch, it still does. All that's changed is that in View Source another option is added -- "Save Highlighted Source" mpt, is this still wontfix in your opinion given my description of the problems involved in getting the color information into copied text and the clarification about what's really going on with the menus? > That is, assuming that the output of this function is *just* (X)HTML If you read the patch, you will see that it is not. My code actually generates strict XHTML with a <style> element in the head which contains all the style information that's in an external stylesheet in viewsource (viewsource.css). The code currently does not output a doctype, so the resulting HTML is not strict. But I can easily add a 4.01 Strict doctype and it would validate. I could do strict XHTML just as easily, of course. The documents created by the view source parser validate against that too.....
Boris, I didn't get a chance to read your patch, don't know if I could anyway. Since you use <STYLE>, though, how are you gonna markup HTML that doesn't recognize that tag? That was partly my point. I'm probably the only one that sees that as an issue, but I get enough problems with MS software generating invalid HTML, I don't want Mozilla doing the same.
> Since you use <STYLE>, though, how are you gonna markup HTML that doesn't > recognize that tag? Perhaps it's not clear how this process works. I save an HTML 4.01 document with a <style> tag. The markup provides highlighting. The text is the contents of the original document (escaped as necessary). For example, for "<html></html>" (a very small document, indeed) I would save: <!doctype whatever> <html> <head><style> .... </style></head> <body> &lt;<span class="start-tag">html&gt;&lt;/<span class="end-tag">html&gt; </body> </html> Since <style> is in _my_ document and my document is HTML 4, it's definitely recognized.
Sorry I don't know C++ well enough to figure out the patch. How does it end lines? Like <html></html> gets output as: <!doctype whatever> <html> <head><style> .... </style></head> <body> &lt;<span class="start-tag">html&gt;&lt;/<span class="end-tag">html&gt; </body> </html> Instead of '<html></html>' if the starting markup is '<html> </html>' then what would go between '&lt;<span class="start-tag">html&gt;' and '&lt;/<span class="end-tag">html&gt;' to make the '</html>' be on the next line? Is it <br> or <br/> or something else? Reading through the bug, I see that Boris first the patch generates XHTML (<br/>) and later it's HTML 4 (<br>). So if you insert a !DOCTYPE (recommended) then make sure it matches the kind of <br> you use. If you don't use <br> then ignore all the above. Another point: it looks like when syntax highlighting is disabled, the option to save the (X)HTML from the view source window is also disabled. (again I don't know enough C++ to tell for sure) It would still be a nice feature to be able to save the escaped markup, even if it's not color-coded. Just a thought...
> if the starting markup is > '<html> > </html>' I have to apologize. I forgot the <pre> tags in my description of the output I create. So to get a newline, I output... a newline. Thus in the '<html>\n</html>' case we would have: <!doctype whatever> <html> <head><style> .... </style></head> <body> <pre> &lt;<span class="start-tag">html&gt; &lt;/<span class="end-tag">html&gt; </pre> </body> </html> > it looks like when syntax highlighting is disabled, the option to > save the (X)HTML from the view source window is also disabled. Correct. This code is in javascript, by the way, not C++.... > It would still be a nice feature to be able to save the escaped markup Escaping the markup is a trivial operation that involves 3 regular expressions (the ones I apply). It hardly seems worth opening a page in a browser to get its escaped markup.
QA Contact: bsharma → moied
Futuring. The UI people mislike this...
Target Milestone: mozilla0.9.5 → Future
bz: Could you elaborate on UI's reasoning? This functionality would be very helpful to web developers such as myself. Would a prefs.js setting make it more acceptable to them?
See the comment by "Matthew Thomas (mpt)" on 2001-08-26 09:38. He's the UI module owner...
bz: Thanks for pointing that out. I can address those concerns. As for "Save As", I wouldn't recommend that name either (as users probably would be confused). But, perhaps "Save Highlighted Source" (next to the usual "Save As") might work. mpt also mentioned copying to the clipboard, but I think that's only a kludge, as Linux (and possibly Mac) don't offer such clipboard functionality.
> as Linux (and possibly Mac) don't offer such clipboard functionality. That's actually not true. You can put things in the X clipboard in the text/html flavor and if the app being pasted into is not dumb, it will get the HTML. Most apps are dumb, however. Mozilla itself is not, I must note. And the menu item I added _is_ called "Save Highlighted Source"! mpt? Comments? You never responded to my comments on this earlier...
Just to clarify, I'm not the UI module owner. That's Ben Goodger for the browser, Seth Spitzer for mail/news, and I-don't-know-who for the editor. Anyway. If you're convinced this is useful, then sure, implement it -- but only after Ben Goodger finishes what he's working on right now for saving complete Web pages with images etc. Part of that work is adding a file type option menu to the Save filepicker, and `Highlighted Source Code' (or something like that) could be one of the options in that menu when a page is saved from the source window. Any other UI for this would be weird.
Priority: P3 → P5
The filepicker-based solution is about as inflexible and hard-to-extend as possible, at the moment. Yay. Reassigning various UI bugs to default owners.
Assignee: bzbarsky → doron
Status: ASSIGNED → NEW
Component: Parser → ViewSource
QA Contact: moied → pmac
I've found a near workaround that is truly wonderful in its unnecessary complexity. In the page I wish to get formatted source for, I execute javascript:window.open("view-source:data:text/html,<html>\n" + document.documentElement.innerHTML + "\n</html>"); void 0; either by typing it in the address bar, or by selecting a bookmarklet with the above as its address. This brings up a standard Mozilla window, displaying the syntax-highlighted source of the first window. In the new window, I then execute javascript:window.open("data:text/html,<html>\n" + document.documentElement.innerHTML + "\n</html>"); void 0; which brings up a third window, superficially identical to the second window but whose actual contents are the HTML needed to generate the third window. I can then select File->Save Page As..., and by choosing "Web page, complete" from the filepicker dropdown I get a HTML file and accompanying stylesheet 'viewsource.css' which together will suffice to display the Mozilla-generated syntax highlighted source in any browser. The one problem with the above is that it takes ages to save the HTML file, perhaps due to some type of recursion - 55 seconds to save the formatted source of www.mozilla.org/start/, with near 100% CPU utilisation during that time; my specs are: build 2002092108, WinXP Pro, Athlon XP 1800+, 768MB PC133 SDRAM. If, however, at the second step I instead execute javascript:window.open("view-source:data:text/html,<html>\n" + document.documentElement.innerHTML + "\n</html>"); void 0; I get a "view-source of view-source" which I can then copy into a plain-text editor (Notepad) and save as a HTML file; although this does not suffer from the excessive performance issues of the first approach, there is a slight problem: the copied HTML file gets its style information from <link rel="stylesheet" type="text/css" href="resource:/res/viewsource.css"> and so will only work in Mozilla and related browsers, unless I either provide the viewsource.css myself (by saving resource:/res/viewsource.css and altering the above line to reference the saved copy) or remove the above line and insert the contents of resource:/res/viewsource.css inside a <style type="text/css">...</style> element. Finally, can I just say that in my opinion, the people most likely to to use view-source will in general be hackers and developers, who will be perfectly willing to put up with 'weird' UI for the sake of the feature; can't we just add the "Save Formatted Source" menu item and file a bug on the UI of it?
Update: the performance lag with the first method has disappeared (my downloads list had become corrupted). The first method is now the better workaround.
Summary: [RFE] Ability to save highlighted source in view-source → Ability to save highlighted source in view-source
Product: Browser → Seamonkey
Assignee: doronr → mrbkap
Priority: P5 → --
QA Contact: pmac → doronr
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Assignee: mrbkap → nobody
QA Contact: doronr → view-source
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
Product: SeaMonkey → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: