Closed Bug 209953 Opened 21 years ago Closed 21 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: 21 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: 21 years ago → 21 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.