Web links appear to be corrupted. 
To Reproduce: 
On Location: enter www.eazel.com and
click on one of the links (jobs page)
The link on the Location: should read "http://www.eazel.com/jobs.html" 
Click on "Engineering." Should get "http://www.eazel.com/jobs.html#Engineering"
but intead I get an error message:
"Couldn't find
"http://www.eazel.com/jobs.html#Engineering".
Please check the spelling and try again.



------- Additional Comments From victor@eazel.com 2000-08-08 17:22:56 ----

Darin, Can you or somebody check this one out?
Don't think we can use this in our demo. 
Cheers, Victor




------- Additional Comments From mjs@noisehavoc.org 2000-08-10 01:21:06 ----

this is demo critical, and I am fixing it
(services demo pages use anchors)




------- Additional Comments From mjs@noisehavoc.org 2000-08-10 06:51:32 ----

I fixed this well enough for the demo on both the demo and release branches.
There are still some issues - mainly the fact that you can't type a URI fragment
reference into the location bar and have it work. I am bumping this to "usable"
since it is no longer a demo issue.




------- Additional Comments From mjs@noisehavoc.org 2000-08-11 00:59:39 ----

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



------- Additional Comments From mjs@noisehavoc.org 2000-09-01 22:46:31 ----

I need to look at the remaining issues. I could help someone else with this if
any kind soul wanted to take it.




------- Additional Comments From robey-bugs@lag.net 2000-09-14 20:15:34 ----

evilness abounds on this one.
here's what i understand from a discussion with maciej:

for html pages, an unquoted "#" is a divider between the real url and a
reference inside that url.  any quoted "#" is part of the url.

for non-html urls, all "#" are part of the url, and should be quoted for good
measure.

it's hard to tell whether an url is an html page or not, until you've already
fetched the content.  some heuristics are obvious, but no 100% solution presents
itself.  one possibility is to quote the "#" first, then try leaving them
unquoted if an error occurs.  that seems really hackish.




------- Additional Comments From eli@eazel.com 2000-10-16 19:29:59 ----

Batch-assigning QA ownership of remaining bugs to eli@eazel.com



------- Additional Comments From bud@eazel.com 2000-11-05 13:18:41 ----

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



------- Additional Comments From bud@eazel.com 2000-11-05 13:19:26 ----

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



------- Additional Comments From robey-bugs@lag.net 2000-11-08 20:08:52 ----

i am extremely interested in advice on this one.

(is it feasible to assume that any # typed in the location bar is literal, i.e.
should be quoted -- but that any unquoted # in an embedded url is a fragment
separator, and should be left unquoted?)




------- Additional Comments From darin@bentspoon.com 2000-11-08 22:42:05 ----

A safe way to tell if a "#" is "literal or not" is by consulting the scheme. We've already 
taken a step in this direction inside gnome-vfs, with rules that make http and 
eazel-services a special case where "#" is a special character that must be left 
unescaped, while for other schemes, "#" is escaped when forming the canonical 
version. Check with Pavel and Mike Fleming for details.



------- Additional Comments From mikef@praxis.etla.net 2000-12-07 18:55:36 ----

Hey Robey--

Let's make this work.  Come bug me and we'll figure it out.



------- Additional Comments From robey-bugs@lag.net 2000-12-11 21:43:07 ----

this is pretty much the lowest priority for me right now because of all the
installer voodoo...  maybe i'll come bug you next month about this. :)




------- Additional Comments From robey-bugs@lag.net 2001-01-04 18:40:44 ----

mike points out that there is also the evilness of gnome-vfs's (poorly chosen)
special "#" behavior for opening tarfiles, etc.  there may be no way to win
here.




------- Additional Comments From darin@bentspoon.com 2001-01-04 19:05:51 ----

I don't think that the gnome-vfs evilness should be preventing this from working. We 
should be able to fix this easily; we haven't yet even debugged this to figure out 
what's going wrong! Lets not psyche ourselves out.



------- Additional Comments From robey-bugs@lag.net 2001-01-05 13:25:26 ----

sorry, this stems from a conversation yesterday about how to determine what a
typed "#" means (and there's probably no definitive way short of reading the
user's mind).  trial and error is probably the only solution.




------- Additional Comments From robey-bugs@lag.net 2001-01-08 18:46:46 ----

okay, you get "the great escape massacre" :)
[mjs suggested making the vfs method separator be "##"]
[yakk suggested treating "#" as an anchor divider for uri's and treating it
literally for direct filenames]




------- Additional Comments From don@eazel.com 2001-01-18 13:51:26 ----

Moving this to 1.0.  This isn't a PR3 blocker ...




------- Additional Comments From mjs@noisehavoc.org 2001-01-30 15:58:01 ----

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



------- Additional Comments From mikef@praxis.etla.net 2001-02-04 21:59:48 ----

The behaviour with file: is even stranger, apparently:

Subject: 
       [Nautilus-list] Wierd Mozilla Content View Behavior
   Date: 
       05 Feb 2001 10:34:55 +0530
  From: 
       Vijay Prabakaran <vijay@linuxfreemail.com>
    To: 
       nautilus-list@lists.eazel.com




Hi,
I am getting some wierd behavior while using mozilla content view. This 
happens when I open a locally saved HTML file. I am taking the example 
of glib-basic-types.html. If I am browsing the page on the web  and I 
encounter a link within the page of the form
http://developer.gnome.org/doc/API/glib/glib-basic-types.html#GBOOLEAN 
then mozilla view works correctly. But now if I try to view the same
file stored 
locally( /home/vijay/glib-basic-types.html) and click on a reference of 
the above form the mozilla content view interprets it as
/home/vijay#GBOOLEAN/glib-basic-types.html and doesn't show the page 
at all. I have tried this both on a  Debian system and a fressh Redhat
6.2 
install and both time it does the same.


Vijay.



------- Additional Comments From duane@eazel.com 2001-02-15 14:57:46 ----

This is definitely an important bug to get fixed as almost all of the pages in
the Help sidebar pane have anchor tags '#' in them and you can not navigate by
the links at all with this bug here.



------- Additional Comments From don@eazel.com 2001-02-16 18:13:14 ----

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



------- Additional Comments From jfleck@inkstain.net 2001-02-18 17:23:06 ----

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



------- Additional Comments From jfleck@inkstain.net 2001-02-24 09:48:20 ----

This is not fixed for me.
Anchors in info files do not work. For example, info:dc#invocation (clicking on
"invocation" link in info:dc) returns me to the top of the page, rather than
dropping me down to the location of the fragment.
Anchors *do* work correctly on html versions of help files.




------- Additional Comments From eli@eazel.com 2001-02-24 15:10:34 ----

jfleck discovered that the issue with anchors in info: files is covered by bug
#46756.

So, I'm going to go verify this one (and all of its duplicates) now.



------- Additional Comments From eli@eazel.com 2001-02-24 16:08:25 ----

Verified fixed. (both this, and every bug marked as duplicate of it.)



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:36 -------
Bug depends on bug(s) 46163.

The original reporter (victor@eazel.com) of this bug does not have an account here.
Reassigning to the exporter, unknown@bugzilla.gnome.org.