Jason Barnabe (np) Reporter
	Description • 19 years ago

Since bug 78510 got fixed, links are only marked as visited when the document
beings loading. While waiting for a server response, the links remain in
unvisited status. This delay is very noticable on servers that don't respond
instantaneously (ex: this one) and when you open links in background tabs.

1. Set new tabs to open in the background
2. Open
https://bugzilla.mozilla.org/buglist.cgi?product=Core&product=Firefox&product=Mozilla+Application+Suite&product=Thunderbird&product=Toolkit&bug_status=UNCONFIRMED,NEW,ASSIGNED,REOPENED,RESOLVED&chfield=%5BBug%20creation%5D&chfieldfrom=-0d
3. Open the links in tabs, notice that they're not marked as visited
instantaneously as before .3

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 1 • 19 years ago

As mentioned in bug 78510 comment 217, this is not really a regression from that
bug. Bug 78510 simply made link colouring always be consistent with history. So
this bug is really about URLs not being added to history instantly.

	Steve England [:stevee]
	Comment 2 • 19 years ago

FWIW I like the way it currently works.

	Tom Mraz
	Comment 3 • 19 years ago

Confirming, however it's debatable if it should be fixed or wontfixed.

	Marco Franzen
	Comment 4 • 19 years ago

"Fixing" this would feel like cheating to me, like a progress bar that shows
progress when there is none to make the app feel faster.

More specifically, if a server is temporarily down etc, then I still want to
visit it when I come to the referring page later again.

See also bug 78510 comment 219 and bug 78510 comment 221.

	Raoul Nakhmanson-Kulish
	Comment 5 • 19 years ago

Agreed with comment #2, this is WONTFIX for me.

	Ben Ruppel
	Comment 6 • 19 years ago

I vote WONTFIX for this bug and my reason follows:
If I open a batch of links in new tabs and one tab does not load properly, it is
helpful to be able to keep track of which link did not load.  This will let me
try again, or at least keep track of what information I have not been able to
access on the referring page.  

In the original bug where this came up, I believe a proponent for this bug noted
that they would rather have links that do not work colored, so that they will
know that they already tried that link and it did not work.  It will also help
them not to mistakenly try to load that link again, thinking that they have not
tried it yet.

In my personal usage, I would want to be able to easily retry a problem link. 
Maybe I would come back to the site the following day and try it, in case the
webmaster fixed it.  Not coloring the link will help me when I try again.  The
worst case is that I will click the link again and get another error page.

If the link is colored immediately, when I come back tomorrow it will be hard to
identify which link did not work.  A proponent might argue that they would like
the link to be colored immediately so that they do not click on the link a
second time while they are on the referring page.  (I believe it is pretty easy
to keep track of which links I have just clicked when I visit a site using short
term memory.)  Anyway, if the links are immediately colored, the worst case is
that I can't keep track of which links I haven't been able to access, and I miss
a link which might have had good information but which was down when I first
tried to access it.  

So, lets compare the two worst cases:
For links not colored until they're loaded, the worst case is I mistakenly click
the link again and get an error.

For links colored immediately, the worst case is I miss a page that I wanted to
view.  I call that DATALOSS :) which trumps the problem of an extra error page
in most cases.

	Jason Barnabe (np) Reporter
	Comment 7 • 19 years ago

Is it at all in the realm of possibility that the links are marked as visited
when clicked and unmarked if an error occurs while loading them?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 8 • 19 years ago

That could be done, probably.

	bassclar
	Comment 9 • 19 years ago

Perhaps the link clicked-on (but not any other links with the same URI)
could be colored :active immediately, then :visited when the document
begins loading (or back to its pre-clicked state if the server is down).

Or rather, since in CSS2 :active is no longer mutually exclusive with
:link and :visited (see
<http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes>),
we could address these no-immediate-feedback concerns by delaying the
removal of :active coloring until the server responds (or definitively
fails to respond).

Am I just nuts, or might this actually make some sense?


PS. Thanks, roc, for your work on bug 78510. The broken behaviour
made me not want to use mozilla. That someone derided your effort
as to merely "make 41 people happy" missed the notion that each
vote represents hundreds (thousands?) of users who are unaware of
the ballots (or just lazy, like me).

	Marco Bonardo [:mak]
	Comment 10 • 7 years ago

too much complication for uncertain benefit.