The IE5 Web Developer Accessories add-on offers the ability to select items of a website and view the source of only that portion, via an item in the context menu. This might be a cool idea for a future release...

->law, future

related: bug 28809, "[RFE] View Source at Selection"

IE's implementation is based on document.selection.createRange().htmlText. We don't have document.selection. IE changes the html code by the way, just like it does when you save a webpage using the default option, so you're not seeing exactly what was on the webpage. Netscape's equivalent of document.selection is document.getSelection(), which returns some text with most html tags stripped and some html tags converted to text equivalents. Mozilla's equivalent of document.selection is window.getSelection(), which returns a selection object. Does anyone know what you do with a selection object? (Bug 32481 tries to explain what's going on here, but I don't quite understand it.) Since I spent forever looking for these links (I just reinstalled windows so I didn't already have them installed): Web accessories for Internet Explorer 5 http://www.asia.microsoft.com/Windows/IE/WebAccess/ie5tools.asp IE5 Web Developer Accessories (including the "view partial source" thing) http://www.asia.microsoft.com/windows/ie/webaccess/webdevaccess.exe

this feature would make debugging parser bugs easier, and it would also make it easier to debug pages containing document.write scripts (for making testcases or writing the scripts).

This should be fairly east to implement as a bookmarklet once window.getSelection() is fixed in bug 48575.

See also bug 60426, ability to view generated source for entire page.

Adding dependency on bug 58970, "Range cloneContents not implemented".

Jesse, If you are still looking for a discription on how to get a partial source and how to use the selection object see my article at: http://www.pbwizard.com/Articles/Moz_Range_Object_Article.htm Jeff.

Adding dependency on bug 70613, "innerHTML of elements that are not in the DOM tree is empty".

It looks like the blockers have been cleared for this functionality. I use it heavily in IE as a DHTML developer, but wonder if there's still a need with the javascript debugger and Venkman. I guess neither app offers the exact capabilities. A way to drill down into computed style properties would up the ante over IE's capabilities.

Range.cloneContents() still doesn't work well. Adding bug 101191, "range.cloneContents gives bogus results most of the time", as a blocker. Since documentFragment's don't have innerHTML, I had to put the documentFragment in a larger object in order to get its innerHTML: javascript:x = document.createElement('div'); x.appendChild(window.getSelection ().getRangeAt(0).cloneContents()); alert(x.innerHTML) Note: IE's documentFragments also don't have innerHTML either. To see that IE doesn't give innerHTML to documentFragments, use this bookmarklet: javascript:alert(document.createDocumentFragment().innerHTML)

*** Bug 119030 has been marked as a duplicate of this bug. ***

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".

Check out what I did for MathML as a matter of necessity: screenshot - Partial viewsource of MathML (WYSIWYG) http://bugzilla.mozilla.org/attachment.cgi?id=66993&action=view Since MathML documents tend to be large due to the fact that the number of MathML tags exceeds the actual content by far, having the ability to locate the partial source of a MathML fragment is useful for those who want to inspect, learn, or... curl the markup. Also, it helps to see the Unicode points or entity names in case of missing glyphs -- something frequent when users lack MathML fonts. See http://groups.google.com/groups?hl=en&th=719389d8ff974cb9&rnum=1 and grab/build a recent MathML-enabled binary to see it live on the MathML demos at: http://www.mozilla.org/projects/mathml/update.html (And BTW, in addition to the initial intention of saving from the hassle of figuring out what a fragment looks like, getting the partial WYSIWYG is much faster that the not-so-fast viewsource.)

*** Bug 124687 has been marked as a duplicate of this bug. ***

IS this a common option? Wouldn't hooking this up to DOM inspector be the way to go? Currently you can click on an element in the tree view to highlight that part of the content. Wouldn't doing the reverse be a more powerful way of allowing this?

I like the way rbs did it, though I think ordinary selection is preferable to highlighting -- that way you can clear the highlighting if the selection was an accident. So, if some of the page is selected when View Source is chosen, then: (1) select the equivalent source in the source window (2) scroll so that the beginning of that section is as close to the middle of the source window as possible without leaving whitespace at the top or bottom. That way there's no need for extra menu items or other cruft in the UI.

mpt: that's bug 28809, which is more difficult to fix than this bug. "View partial source" in IE shows part of the *generated* source, which I think makes more sense than trying to match up the selection with part of the source HTML (especially in documents with javascript).

I just added a "Partial Source" bookmarklet to http://www.squarefree.com/bookmarklets/webdevel.html. It works in nightlies but not in 0.9.9.

-> off-loading this from law's back and re-assigning it to myself. I have this working. Starting with what jruderman did (see, e.g., comment #11): x = document.createElement('div'); x.appendChild(window.getSelection().getRangeAt(0).cloneContents()); alert(x.innerHTML) I fed the result in the view-source machinery using the 'data:' protocol with the innerHTML escaped appropriately (bug 136538), et voila, syntax hightlighted partial WYSIWYG viewsource is there, with configurable wrap long lines for large selections. See attachment 77958 [details] for an idea of how it looks like (note: for this bug, the MathML markup is just replaced with the syntax highlighted markup of the selection). For lack of a better terminlogy, I have been using the 'WYSIWYG' term to hint at the fact that it is a generated source from the DOM, i.e., it may have already been munged through JavaScript scripts in the document. There have been suggestions to drop this WYSIWYG term althogher. If someone has an easy to say what is happening, do well to tell. Having now had a chance to experiment with both modes (View Selected Source i.e. this bug, and View MathML Source i.e., bug 122524), I still had the feeling that the MathML situation remains rather peculiar. See for yourself how the amount of MathML markup exceeds by far the actual textual content in attachment 77958 [details]. There are lots of tags. Yet, when leaf nodes are eventually reached, they often just have single characters. The MathML markup can easily become cryptic if not reformatted nicely. So, here is what I propose in order to limit the "need for extra menu items or other cruft in the UI": - If there is a selection (whether it crosses a MathML boundary or not), and the user does a right-click, let the context menu have "View Selected Source". (it should be noted that "View Page Source" doesn't show up if there is a selection. So only selction-aware items appear: "Web search for selection" and now "View Selected [WYSIWYG] Source/Markup"). - If there is no selection, and the user does a right-click *on* MathML, let "View MathML Source" appear alongside the normal "View Page Source" as bug 122524 is suggesting. Thoughts?

The editor has "EditorTestSelection" in its debug menu, which might be of some interest to folks in this bug: http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/EditorCommandsDebug.js#75 Ignore the editorShell calls, the potentially useful part is the selection.toStringWithFormat call (which can also generate text/html and can take different output flags). It doesn't address the issue of the View Source colorizing or anything, though, and may not do anything that the bookmarklet doesn't already do (I haven't looked yet).

I have switched to akkana's suggestion. ...But it is XUL only, for I had to QI to get it to work (so not for a bookmarklet since security won't allow it). The code for that now reads in a more compact way as: var selection = <the-focused-window>.getSelection(); if (selection && !selection.isCollapsed) { source = selection.QueryInterface(Components.interfaces.nsISelectionPrivate); .toStringWithFormat("text/html", 0, 0); }

I have the mutually esclusive options (as described in comment #20) now working: View Partial Source or-exclusive View MathML Source; with the precedence given to the selection when there. I will attach the patch sometimes next week (in the other bug 122524). In the meantime, if people have better suggestions for the names, chime in...

about ".toStringWithFormat("text/html", 0, 0);" - does that always make text/html out of the selection? do we want this?

Yes, from my testings, it does the most generic formattings. e.g., selecting a piece of JavaScript makes it appears as CDATA, i.e. "as-is" with the original identations preserved. Selecting XML recovers all the tags, i.e. what is needed. And of course selecting HTML is home.

This is a screenshot which is a miniature version of bug 28809. I ended up having some misgivings with the earlier simplistic view partial source because it didn't fit well with MathML in particular and was limited in general: 1) For MathML, doing the simplistic partial source led to invalid markups. To undestand why, notice that the |toStringWithFormat| function (which boils down to the same back-end code as innerHTML) returns a *well-formed* fragment. This means that if you chop the selection somewhere, all the tags that were left open appear as closed in the output. For example, if you have a fraction: <mfrac> numerator denominator </mfrac> and position the selection to look like: [<mfrac> numerator] denominator </mfrac> then the generated output will be: <mfrac> numerator </mfrac> which doesn't make sense (it is *well-formed* but *invalid* per the MathML DTD). 2) Secondly, for the general case, just selecting a fragment and dumping it out of its context (with tags closed at the wrong place due to the well-formedness...) leaves a lot to be desired once you start looking... Try out jruderman's bookmarklet to see what I mean. === So, I made a new patch that uses a 'common ancestor' of the selection points to return a *contextual* view selection source (see screenshot). For example, if one selects a text inside a table cell, rather that just dumping the plain words that were selected (which wouldn't be that informative), it instead shows up as: <td> ...selection... </td> But since in general the selection can be intermingled with anything, I basically had to address bug 28809. So bug 28809 is particular case now by taking the 'common ancestor' in my patch (bug 122524) as the top-level <html> element in the document. However, bug 28809 looks mot to me now and I suggest to WONTFIX it altogether. The view selection source in context seems to cover most of what is needed (and closing few tags helps to stay closer to sloppy HTML). The end-result is still well-formed. For XHTML, that's fine. It matches the orignally perfectly. For slopply HTML, using the 'common ancestor' helps to keep the selected fragment in its context as much as possible, while pushing the closing of tags further down the output. There isn't much else to expect since this a generated output from the (well-formed) DOM. Bug 122524 is for the technicalities of how the patch works.

In addition to the other benefits alreaday mentioned, this capability is also proving useful to capture XSLT generated fragments. XSLT does a DOM-to-DOM transformation, and the classical view-source gives the original static document (i.e., with the initial XML processing-instruction to invoke XSLT, etc), whereas with this option now available, one can peek at the actual generated output without much fuss.

Fix from bug 122524 was checked in. I made a typo in the checkin comment: the bug numbers should read b=49721,122524 (rather than 1222524).

Verified on netscape trunk build: 2003-01-09-08-TRUNK.

*** Bug 209953 has been marked as a duplicate of this bug. ***