Closed Bug 49721 Opened 24 years ago Closed 22 years ago

[RFE] View Partial Source capability

Categories

(Core Graveyard :: View Source, enhancement, P3)

Product:
Core Graveyard
Component:
View Source
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: rbs)

References

Details

(Keywords: helpwanted)

Attachments

(1 file)

screenshot - rendering of a much improved view selection source
32.27 KB, image/png
Details 
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
Assignee: ben → law
Target Milestone: --- → 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".
Depends on: 58970
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".
Depends on: 70613
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)
Depends on: 101191
*** 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".
QA Contact: sairuh → pmac
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?
Assignee: law → rbs
Component: XP Apps: GUI Features → ViewSource
Target Milestone: Future → ---
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);
}
Status: NEW → ASSIGNED
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...
Depends on: 136538
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).
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified on netscape trunk build: 2003-01-09-08-TRUNK.
Status: RESOLVED → VERIFIED
*** Bug 209953 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
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: