1081877 - Visited links with long urls don't show purple as expected.

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect, P5)

Description

[henrik.lievonen]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140923175406

Steps to reproduce:

1. Visit site: http://www.ohjelmointiputka.net/keskustelu/uudet.php (A Finnish programming forum, the list of recent discussion).
2. Open one of the links in the list under "Aihe" (Subject). (Like "Android Studio - 'Gradle project sync failed'")
3. Go back to the previous page (in step 1).


Actual results:

The visited link shows in blue.


Expected results:

The visited link should how in purple.

Comment 1

[henrik.lievonen]

My device is a brand new Nexus 5 (D821) with Android 4.4.4. The same problem happens also on other sites like Google.

Comment 2

[Aaron Train [:aaronmt]]

The site defines it's own a:visited, which doesn't seem to take affect on hitting back. Desktop adheres to this styling.

a:visited {
color: #633;
}

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]

Comment 6

[u535116]

I would like to help fix this bug, and would like mentor help. Where should I start?

Comment 7

[Gian-Carlo Pascutto [:gcp]]

This bug has the "regressionwindow-wanted" keyword set, so if you are able to make your own Firefox for Android builds, then trying to bisect (with Mercurial) the commit that caused this problem would be a good start.

Comment 8

[u535116]

Not sure where to look for the code that would alter this behavior, any tips?

Comment 9

[Gian-Carlo Pascutto [:gcp]]

The comment above yours explains how to find the code that caused the problem.

Comment 10

[u535116]

Sorry, I think I'm missing something, I don't see the comment you're referring to.

Comment 11

[Gian-Carlo Pascutto [:gcp]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1081877#c7

None of that requires knowledge of the codebase or looking for any code - it just consists of building historical versions of the code to see where the problem was introduced, thus giving you the code changes that caused the problem. That will narrow down the place to start looking immensely.

Comment 12

[James Willcox (:snorp) ([e-mail]) (he/him)]

You can use mozregression[0] to narrow it down to a specific Nightly first. I don't think we know the last time it worked, though, so that would be the first part you'd need to figure it out.

[0] http://harthur.github.io/mozregression/

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

I don't think this is bfcache related. Refreshing the page also shows no visited link status. I used the remote debugging tools to inspect the page itself. the "a:visited" state did not kick in.

I think we should start by looking at the place where the "visited" state is passed back to Gecko:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GlobalHistory.java

Comment 14

[Mark Finkle (:mfinkle) (use needinfo?)]

I put some logging into the code and found the <a> links look like:
http://www.ohjelmointiputka.net/keskustelu/28605-javascript-periytys/v-227204

But the actual page URL (added to history) is:
http://www.ohjelmointiputka.net/keskustelu/28605-javascript-periytys/sivu-1

The page does a redirect, possibly on the server. The Android code is designed to ignore redirects, so the useless URL is not displayed in the Awesomescreen or Top Sites along with the actual destination URL.

I looked on Desktop and Desktop puts both URLs in history:
http://www.ohjelmointiputka.net/keskustelu/28605-javascript-periytys/v-227204
http://www.ohjelmointiputka.net/keskustelu/28605-javascript-periytys/sivu-1

WONTFIX?

Comment 15

[u535116]

I used mozregression and the problem appears as far back as I can possibly go until the builds won't run on my current device with Lollipop or an emulator with the previous OS (Jelly Bean). This goes back to 2013.

Comment 16

[u535116]

(In reply to Mark Finkle (:mfinkle) from comment #14)
> WONTFIX?

The behaviour on the desktop works as expected, so I would expect that the Android version would match.

Comment 17

[Kevin Brosnan [Ex-Mozilla]]

We don't store all the data that desktop does for history to keep the file smaller and have better performance on low end devices.

Comment 18

[Gian-Carlo Pascutto [:gcp]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #17)
> We don't store all the data that desktop does for history to keep the file
> smaller and have better performance on low end devices.

Well yes but being able to correctly show which links a user clicked isn't something we should optimize away, probably.

Comment 19

[u535116]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #18)
> (In reply to Kevin Brosnan [:kbrosnan] from comment #17)
> > We don't store all the data that desktop does for history to keep the file
> > smaller and have better performance on low end devices.
> 
> Well yes but being able to correctly show which links a user clicked isn't
> something we should optimize away, probably.

Agreed, we shouldn't sacrifice basic functionality for what seems like negligible performance gains.

Comment 20

[henrik.lievonen]

Note that the links turn into visited if I visit them on a computer and then use Sync to synchronize history to Android. I guess this means the redirecting URL is also synchronized to Android so there is no memory gain in not saving that URL on Android device.

Comment 21

[Mark Finkle (:mfinkle) (use needinfo?)]

I don't want to add support for this until we change the way the URLs are displayed in Top Sites, Awesomescreen and other places. The redirected URLs should never be visible to the user and the Android history DB schema can't separate them right now.

There is a different bug about changing our history storage to allow for a "visit type" and then we could tag the redirects as "redirect", using that to filter them from UI visible lists. Since the URLs would be in the DB, they'd be "found" when looking for visited links.

See bug 934702 for bugs about local storage and bug 1046709 for issues around syncing from desktop.

Comment 23

[Bogdan Surd, QA [:bsurd, NI]]

After running a mozregression, it would seem that the issue is reproducible since the first build(2014-08-08) that I was able to install on my device. Any other builds sooner than 2014-08-08 instantly crashed or just didn't start up. I can confirm that the issue is still reproducible even on the latest versions of FF. In Comment 15, Matt went as far as 2013 and the issue was still reproducible.

For build 2014-08-08: 
application_buildid: 20140808030201
application_changeset: 18f408a5984e

Seeing as a valid regression window can't be found I am removing the regressionwindow-wanted keyword as it is no longer needed.

Comment 24

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.