343271 - Enhancement: named anchor syntax (#anchor_text) in URL finds text on page, if no such anchor exists.

Status: NEW

(Toolkit :: Find Toolbar, enhancement, P5)

Description

[Hilary Mark Nelson]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Basic concept: 
If I enter a URL like this:

http://host.domain.com/path/page.html#This%20is%20a%20line%20of%20text%20on%20the%20page

...then Firefox would go to that page and if it can't find an anchor that matches, then it would search for that text on the page and jump to the first occurrance.

The result is that users can send people links to arbitrary points on any page, regardless of whether there's actually an anchor there.

This may be useful for Disability Access as well.

To make this really useful, there should be a contextual menu item available if I select text on a page and right-click it: "Copy link to this text on page", or something like that. That would make it pretty painless to send someone one of these links.

Finally, it would be nice if Firefox would hilight the anchor text on the page when you jump to it, so it's easy to spot the point that you're trying to find.

This is my first post to Bugzilla, and I wouldn't have thought this was the appropriate place for a feature request, but the "Keyboard: Find As You Type" module description page said it was OK:

http://www.mozilla.org/access/type-ahead/#We%20Like%20Feedback

( If the feature I'm requesting existed, that URL would jump you down to the passage I'm talking about.  ;-)


Reproducible: Always

Steps to Reproduce:
None, since it's an enhancement suggestion, not a bug.

Comment 1

[Jesse Ruderman]

A few days ago on IRC, someone and I were discussing a similar idea for an extension, where a "#find:foo" anchor for any page would scroll to and select "foo".

Comment 2

[Phil Ringnalda (:philor)]

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

Comment 3

[Dav4is]

Copied from my dup #343912. See summary of important pointe at bottom.
(I thought that I had covered all the bases in looking for prior requests!)

FireFox handling of Fragment Identifiers in HTML documents is well known:
Render the page then scroll to the anchor identified by the #Fragment via named
A tags, or ID on other tags within the document.

This proposal applies to those cases of HTML documents where a #Fragment is not
found in the above sense.

Proposal
FireFox should provide a user option to extend the fragment locator by
automatically treating unfound fragments as find requests.

Elements


    * Whether to do a Match Case find or not may be specified as a sub-option.
    * If the URI identifies a new document, the find context should be the top
of the new document.
    * Otherwise, i.e. the link consists of only the fragment identiifier, the
find context should be the position of the referencing A tag making the link.
    * A link containing any URI part (before the hash mark) is treated as a new
document even if identifying the same one as currently displayed -- i.e. the
find context is the top of the document.



It is my belief that this proposed action is permitted by current HTTP and HTML
architecture and specifications.

Usage
The proposal will be particularly useful in those cases where an author of one
document wishes to refer to a part of another document but the author of the
second document has not identified that part by an attribute in the markup.

Considering the failure to locate an anchor in the document matching a given
Fragment Identifier to be an error, the user agent is free to correct that
error with the user's consent, which consent may be in the form of a previously
selected option. I refer you to the Error Handling section of Architecture of
the World Wide Web (http://www.w3.org/TR/webarch/#error-handling). Also:
http://www.w3.org/DesignIssues/Fragment.html

%%%%%%%%%%%%%%%%
SALIENT POINTS:

1. Must be controlled by a user option, with sub-option for Match Case find or not.

2. Context is specified for the find when the URL specifies only the Fragment Identifier -- i.e. is for the current page. Otherwise, the find context is the top of the document.

Comment 4

[Jesse Ruderman]

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

Comment 7

[gliu20]

See also --> Bug 1753933