Closed Bug 209953 Opened 22 years ago Closed 22 years ago

View source fragment option needed on right-click menu

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 49721

People

(Reporter: L.Wood, Unassigned)

Details

When I right-click on a page, I have the option to View Page Source. Which generates a window with the source of the page, but does not take advantage of the position of the cursor when I right-clicked. I may as well have just selected Page Source from View menu on the menubar. Being able to highlight or indicate the area of source related to what was clicked on would be useful; pages are getting bigger and more complex, and scrolling through the entire source trying to find the right html fragment is quite tricky. If right-clicking, the resulting source window could scroll to that highlighted area. This would be a 'View Related Source' option replacing the not-very-object-oriented and redundant 'View Page Source' in the right-click menu, or somesuch.
Unless I'm missing the point, you've just described the already existing View Selection Source option available when you highlight a piece of a page and right-click it....
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Ah, thanks. I'd missed that. And here I am thinking I know how to use mozilla... 'View Page Source' itself isn't context-sensitive; why have it on a context menu? It would be nice to indicate the cursor position in the source by default. So, this has turned into an improve-usability-request.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
There is no way to associate a part of the source with a part of the displayed page, due to DOM modifications that the page can make. So I'm not sure what the request here is... please explain?
If you can highlight an area and have the html for that area displayed with View Selection Source, it should be possible for mozilla to identify the cursor position, what it's pointing at, and what the minimum we-could-have-highlighted-it area around it is. And then just display the html for that area once the menu option is selected. So, if I'm pointing at a link, I'd get an anchor href of some description back. (bad analogy - bit like double-clicking in Word and having it highlight an entire sentence.)
The minimal "we could have highlighted it" area is always a single character.
yes, the minimal highlight is a single character. The cursor tells you that character. You then look both ways for tags; upwards for opening tags, downwards for closing tags. For each tag, you find its mate on the other side, if it has a mate. Outermost extenal pair wins. Voila, you have a block of source code.
Won't that usually get you <html> / </html>, i.e. almost the whole page?
In fact, it will. Always. For HTML pages, eg.
I guess my brief summary of the algorithm wasn't clear. It's very very simple: Find character. Look upwards. Find nearest opening tag #1 Look downwards. Find nearest closing tag #2. For opening tag #1, look downwards from character to find associated matching closing tag #1. How long is the area between opening #1 and closing #1? For closing tag #2, look upwards from character to find associated matching opening tag #2. How long is the area between opening #2 and closing #2? Whichever of #1 or #2 gives you the longest text area wins - although this presumes well-formed source, naturally. Return that text area as highlighted. This is not recursive. You don't go looking for further-out tags.
...or even the shortest string of the two, not the longest. doh.
Why? That is, what is special about the innermost tag that would make this algorithm useful?
Also note that you are suggesting we show serialized DOM (like view selection source does), instead of the actual source of the page. The character in question, as well as everything surrounding it, may not be present in the original page source.
the innermost tag gives you a self-contained fragment for cutting and pasting. With a reasonable assurance. that it doesn't have unclosed tags within it. Yes, this does the same as View selection source. But it's automatic in context, and beats the default View Source option on right-click menu, which isn't particularly context-sensitive outside a frameset.
The point of the context view-source option is to view source of pages where there is no menubar (alas too common these days). I still fail to see what the use of the option you propose would be.... why would one want to use it?
View source on a window sans menubar is no subsitute for a 'show menubar' option. The point of this feature is to easily and intuitively copy and paste source. Highlighting first for View selected source won't automatically get you a valid self-contained block.
Really? I can't think of a situation where view selection source will fail to produce a self-contained block....
dup of bug 49721. One can select as little text or as much text as desired to get a smaller or wider surrounding context in the DOM source. Comment 15 seems to have been made in haste without double-check. A particular feature of view selection source is precisely that it is well-formed (with Ctrl-A, people often benefit from that to transition to XHTML from their tag-soup HTML pages). Another unique aspect so far is the re-mapping of the selected area in the source. Other attempts (via the bookmarlet or the IE view partial source add-on) chop the source in very unpleasant ways (see bug 49721 comment 26). *** This bug has been marked as a duplicate of 49721 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.