Addition of a contextual menu item when text is selected on a web page. The item "View Source at Selection" would bring up the page source code with the web page selected text already highlighted. This assumes that the browser is using the internal source viewer and it has not been redefined as an external program. Not sure how complicated it would be to select the text in the view source window, but if the window could be brought up to the point of the select would still be benifitial to developers that have large complicated pages.

Why not make this default behaviour? It should show the source as close as possible to what is showing on the screen. This is especially useful in the context of bug #12111.

the problem is, this is impossible almost. when you view the source, you view the actaul html code, not the generated code. So, cgi scripts and whatnot that create text or javascript would cause problems. In netscape 4.x, view source whould show the generated html, which would have made this possible. Moving to XPApps, where it belongs.

I can't see how CGI scripts would cause problems as as I understand they deliver HTML just the same as everything else. Use of the DOM to alter the document is another issue entirely. Perhaps we could have a real-time DOM view added to the DOM viewer (or does it does this already?) that could achieve this, but if this feature was reserved for pages that have not been changed, you could still achieve this in the vast majority of cases. It would probably be a good idea to report in view source whether the DOM has changed from that generated from the source, anyway.

IE 5 has a feature like this, "view partial source" when stuff is selected, but I'm not sure whether that's part of the default installation of IE 5 or what. I like this idea better because it would show the source of what the browser interprets as the relevant part _in the context of the rest of the source_. That CGI problem sounds like bug #6119, view source tries to reload page. This RFE depends on 6119 being fixed.

spam: moving qa contact on some bugs from paulmac to sairuh@netscape.com

pardon the spam: moving view source bugs into xp apps: gui component.

related: bug 49721, "[RFE] View Partial Source capability"

See also bug 47040 for composer, keep insertion point in same place when switching to and from "html source" mode.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

Rather than adding a `View Source at Selection' item to the context menu, which would look absolutely bizarre to the majority of users who don't even know what source is, you could just always select the same content in the source window (when it is opened) as is selected in the browser window.

actually, you can't. at least in the future, a selection can include things that are not sourcewise-close to eachother.

mpt: that would make it hard to discover this feature, since most of the time nothing is selected in the browser window.

The first step would be to have view the source at the beginning of the selected point. While I think an additional contextual menu would be the best solution, it could easily be the default mode (or a option via the settings) to work when something is selected in the page. Will a new person know what it means to "View Source At Selection"? Probably not, but it only takes one time for them to learn and if you're looking to see how a particular section of the page is coded, this feature adds so much value for large pages.

Sorry, I don't believe this feature depends upon <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=60426">60426</a>.

mpt: I covered that already. timeless: I covered that already. jesse: I don't see how it's hard to discover, because if someone wants to do this, it would be the first thing they would try.

Taking...

isn't bug 49721 actually a dupe of this? I like mpt's idea about selecting same things in viewsource as in window. would be nice if that as well as "View Source at Selection" were implemented.

Anyone up for taking this?

The difference between "view source at selection" and "view partial source" is "at selection" shows the entire source, except with part of it highlighted and the window scrolled (if necessary). "Partial source" cuts out everything not highlighted so the source window loads faster (i.e. at selection loads the entire page, partial source loads only a portion). Each has its benefits: sometimes you want to be able to see the context, but not to have to search the file for the place you want to start (at selection), and other times you want only a certain part, and don't need the context (partial). Hope this helps.

--> doron

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

The desired intention of the bug was (mis)quoted in bug 49721 comment #17 by mpt: <mpt> if some of the page is selected when View Source is chosen, then: (1) select the equivalent source in the [view] source window (2) scroll so that the beginning of that section is as close to the middle of the [view] source window as possible without leaving whitespace at the top or bottom. </mpt> This is a tough bug since it requires recovering the poisition of the selection in the *inflated* viewsource DOM. It might be possible to use FIXPtr to get the starting & ending points of the selection. A FIXPtr is a compact string to locate any point in the DOM. It is somewhat the "label" that one might get when walking the DOM, e.g., the pointer "/1/5/12(6)" identifies the 6th character of the 12th child element inside the 5th child element inside the root element of the document. heikki has recently added support for FIXPtr in Mozilla: http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001AprJun/att-0074/01-NOTE-FIXptr-20010425.htm [The current implementation only evaluates a FIXptr string back to the DOM world. Looks like it will also be good to have a reciprocal function -- i.e., a helper function to create a FIXptr string given a position in the DOM (e.g., a selection/caret point).] Some thoughts on fixing this bug: -> use FIXptr to capture the "begin,end" of the selection -> then use "view-source: URL?selection=begin,end" as the viewsource URI -> try to recover the "begin,end" selection in the *inflated* viewsource DOM ...hard

I'd love to know how you are going to cope with selections that half-match the original document because of DOM manipulation... Shouldn't this use the DOM-generated source rather than the original source?

>I'd love to know how you are going to cope with selections that half-match the >original document because of DOM manipulation... It won't work reliably. >Shouldn't this use the DOM-generated source rather than the original source? Memory hungry but that would offer a reliable way to recover the selection. Were people asking for View WYSIWYG Source or what? [Myself, sometimes I am interested in the classical view-source (from the cache), sometimes I instead like the view WYSIWYG source (from the DOM). Now that I have that patch for bug 49721, I can select the whole doc to get the latter--well almost, since the outer tags don't show up + it is a bit innefficient to do it that way, but...]

Suggesting WONTFIX now. I have a patch in bug 122524 that implements a miniature version of this bug. It seems to me to be what is mostly needed in practice, and albeit the patch also solves this bug, displaying just a portion of the source looks nicer, faster, and it saves memory. See bug 49721 comment 26. Screenshot at: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=79770

Agreed. WONTFIX in favour of an equivalent feature.

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

verified