Closed Bug 703532 Opened 9 years ago Closed 6 years ago

Visited links are no longer purple (works with javascript disabled)

Categories

(Toolkit :: Places, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: wirbellosen-auktionshaus, Unassigned)

References

()

Details

(Keywords: regression, testcase, Whiteboard: [testday-20120615])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/534.51.22 (KHTML, like Gecko) Version/5.1.1 Safari/534.51.22

Steps to reproduce:

We are the operator of the internet platform

http://www.wirbellosen-auktionshaus.de/

In all other Browsers (Internet Explorer, Safari, Firefox 3) this problem does not exist:

The problem only exists in the new Firefox Versions: Firefox 4 and all later Versions (Firefox Mac 8, Firefox Windows 9.1):

Problem: Some visited links (only the auction links) are no longer in another color (for example purple).


Actual results:

1. Klick the start page

http://www.wirbellosen-auktionshaus.de/

and then:

2. Then klick:

Top-Angebote	Alle Top-Angebote ...

or

Beliebteste Auktionen	Alle bebotenen Auktionen ...

or

Auslaufende Auktionen	Alle auslaufenden Auktionen ...

or

Heute neu	Alle neuen Angebote ...

3. Then choose one (any) auction

4. Then go back with the "back Button" or "x"-Button

-> Visited auction links are not in a different color (for example purple)


Expected results:

All other visited links are in other color (purple), for example "Nutzungsbedingungen (AGB und Datenschutzerklärung)" or "Widerrufsrecht". Also visited auction Links should become another color. 

Reason: The Firefox Users want to know urgently, what auctions are new for them and what auctions are "old", they want to know what auctions they already have visited (what auctions they already know).

Our engineer told us that this is a Firefox problem. What can we do? Wen want that the visited auctions are in a different color like it was in the year 2010 with older firefox Versions.

Thank you. Best Regards.

Please contact me:

Dipl.-Ing. Dieter Heeger
Einzelunternehmer                
Frühlingstraße 6a
83093 Bad Endorf
Germany
E-Mail:

wirbellosen-auktionshaus@t-online.de

Phone: 0049 160 152 7 554
> http://www.wirbellosen-auktionshaus.de/
> In all other Browsers (Internet Explorer, Safari, Firefox 3) this problem does not exist
I see the same result in Fx8, Opera 12, Chrome, IE8

> Please contact me:
Bo private conversation, sorry
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24
Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0

An observation:
If I do the STR from comment 0 in Firefox 3.6.24 and then visit the site using the same profile with Firefox 8.0, then the links are still marked as visited in Firefox 8.0. But links visited in Firefox 8.0 does not show up as visited in Firefox 3.6.24.
Last good nightly: 2010-07-15
First bad nightly: 2010-07-16

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c&tochange=96de199027d7
Keywords: regression
OS: Mac OS X → All
Hardware: x86 → All
A wild guess from the regression range in comment 3:

Bug 556400 - Add visits Asynchronously. r=mak r=sdwilsh sr=bz 
https://hg.mozilla.org/mozilla-central/rev/f53b8815bb30
Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0

I can't reproduce this. I followed the STR and the visited auction links were purple.
Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
I'v to correct me:
Can reproduce on XP with Fx8 and Opera 12alpha. Works as expected with IE8 an Chrome 14
Works with javascript disabled.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Summary: Visited auctions (links) are no longer in another color (for example purple) → Visited links are no longer purple (works with javascript disabled)
Blocks: 556400
That doesn't seem like a layout issue....  A minimalish testcase would be really nice here, though!
Component: Layout → Places
Product: Core → Toolkit
QA Contact: layout → places
Looks like browser detection:

http://www.wirbellosen-auktionshaus.de/styles/javascript1.js

function LinkConvert(element,action,button) {
 if (action != '') { script = 'javascript:ActionSubmit(\'' + action + '\')'; }
   else { script = 'FormSubmit()'; }
 if (document.forms[0].k.value < 16 || document.forms[0].k.value > 17) {
   if ((button < 2 && (navigator.userAgent.toLowerCase().indexOf('msie')!=-1 || navigator.userAgent.toLowerCase().indexOf('avant')!=-1)) || (button < 1 && navigator.userAgent.toLowerCase().indexOf('msie')==-1) || (button = 1 && navigator.userAgent.toLowerCase().indexOf('safari')!= -1)|| (button = 2 && navigator.userAgent.toLowerCase().indexOf('safari')!= -1) || (button = 0 && navigator.userAgent.toLowerCase().indexOf('chrome')!= -1)) {
     document.forms[0].action = element.href; element.href='javascript:' + script; window.status= element;
   }
 }
}
(In reply to j.j. from comment #9)
> Looks like browser detection:
> 
> http://www.wirbellosen-auktionshaus.de/styles/javascript1.js

Yes, apparently this is sniffing, but how is that related to the current problem? I've not been able to make Firefox nightly work by faking another user agent string.


Unfortunately I've been to lazy to minimize a testcase, but before giving up I found that at least the following parts seem to have something to do with the problem in one way or another:

…
<script language="JavaScript" type="text/javascript" src="topauktionen.cfm_files/javascript1.js"></script>
…
<body rightmargin="0" leftmargin="0" topmargin="0" onkeydown="document.forms[0].k.value=event.keyCode;" onkeyup="document.forms[0].k.value='';" onload="jsclear();" alink="black" link="black" marginheight="0" marginwidth="0" vlink="black">
…
<td bgcolor="white"><font class="default"><a class="auctions" onclick="window.status='';" onmouseout="linkclear(this);" onmousedown="LinkConvert(this,'',event.button);" onmouseover="LinkSet(this)" href="http://www.wirbellosen-auktionshaus.de/auction/17210/snow_white_low.cfm">Snow White low</a></font><br/></td>
…
Attached file testcase (imperfect)
Keywords: testcase
Is this actually a regression on that testcase?  What's the range for the regression?
Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1

I see a regression from Fx3.6. 
STR: 
click one of the links
confirm https warning
wait until new page loads completely
press back button
result:
link is blue, should be purple

This is reduced from the reported URL, so the range should be as in comment 3.
See, that's the thing.  I can't get any sort of visited link coloring on that reduced testcase in 3.6.....
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24
I definitely see purple colored links
I confirm this bug at Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0a1

I have followed both STRs (comment 0 and comment 13).

I noticed that if the link is opened in a new tab/window then the coloring is normal.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [testday-20120615]
Attached file Simplified testcase
The problem appears to be caused by the use of the POST method to submit the form. The resulting page URL never gets added to the history, which is why the link isn't marked as visited.

The attached testcase demonstrates the problem. It fails in Firefox (I tested 3.6.28 and 14) and Opera, but works in Chrome.

(Note: in Opera, the href of the link is not reset after you return to the page. You need to reload the page to see the correctly updated link colours.)
Attachment #633546 - Attachment mime type: text/plain → text/html
(In reply to Boris Zbarsky (:bz) from comment #14)
> See, that's the thing.  I can't get any sort of visited link coloring on
> that reduced testcase in 3.6.....

It works for me in 3.6 if you try two (different) Links (i.e. Click Link1 -> Back: Click Link2 -> Back => Link1 is colored).

Comment 17 seems to be a different Issue since I can repro that one back to Firefox 3.0 and it works in Firefox 2.0.
As far as I can see, both comment 17 and the reporter's problem are caused by the same issue, which is that pages loaded as a result of a form POST are not added to history.

The reporter's site handles clicks on auction links by POST'ing a form to the link URL in the link's 'mousedown' handler. The URL doesn't get added to the history when that's done, and so the link is never shown as visited when you go back to the page.

You can reproduce the underlying problem with this simple HTML:

<form method="post" action="http://www.mozilla.org/en-US/">
<input type="submit">
</form> 

If you load that in Firefox and press the button to submit the form, the resulting page - http://www.mozilla.org/en-US/ - is not added to history. I think that's what the bug is here.
(In reply to XtC4UaLL [:xtc4uall] from comment #18)
> It works for me in 3.6 if you try two (different) Links (i.e. Click Link1 ->
> Back: Click Link2 -> Back => Link1 is colored).

That doesn't work for me in 3.6, on either the comment 11 testcase or the reporter's website. All the links stay blue.
FWIW, we don't add POST visits to history by choice, doing otherwise can easily pollute history with post pages that are unlikely useful.  This filtering is done directly in the docshell.
and the post filter has indeed been added in bug 556400, so the regression range is correct.

If we want these to be properly marked as visited, we may add them as embed visits, then they would be marked visited just for the current session. This likely depends on what's the common behavior among other browsers and whether there are good use-cased for this link coloring on the Web.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.