The default bug view has changed. See this FAQ.

Visited link coloring is visibly slow after refresh or after going back to page

RESOLVED WORKSFORME

Status

()

Toolkit
Places
P3
normal
RESOLVED WORKSFORME
7 months ago
4 months ago

People

(Reporter: Adrian Sampaleanu, Unassigned)

Tracking

(Depends on: 1 bug)

48 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 months ago
Created attachment 8783331 [details]
slowrefresh.gif

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160726073904

Steps to reproduce:

Go to https://www.mail-archive.com/vortex-l@eskimo.com and visit many messages



Actual results:

After many messages have been visited (majority of the messages visible on one page), and coming back to the main page showing the message threads will initially show the color of links as blue (unread) after which Firefox relatively slowly (over 5 seconds) updates the link colors to black (visited). This slow refresh of the link coloring also happens when refreshing the page.


Expected results:

Visited links should show as read (black) instantly (or with hardly noticeable delay).

I only notice a delay on this particular site and it's been happening for the last few months now, IIRC (it used to be OK prior to that). I'm not sure if there was some rework on the site when the problem started or whether it was coincidental with a version change in Firefox.
(Reporter)

Comment 1

7 months ago
Note that I've been visiting this site for years and so if Firefox takes all of my history into consideration when it renders just the visible page, I can imagine that there would be lots of links to consider. Possibly this is what's causing he rendering slowdown. If this is the case, it would be nice to have a way of specifying the deletion of history for a site only for items older than a certain date.
I cannot reproduce the issue, after opening 30 items on clean profile.
Does the issue happen on safe mode and another clean profile?

If the issue doesn't happen on safe mode, it could be the issue from add-ons.
If the issue happens on safe mode but not on clean profile, your history items may be related.
Flags: needinfo?(nmanole)
(Reporter)

Comment 3

7 months ago
In the developer version of Firefox (with the same add-ons as in the release version I generally use) I can't reproduce this either with a similar number of visited links as you, @Tooru. It very well could be the very large number of pages I've visited on this site over the years. The thing is that I don't want to wipe the complete history as I often go back a month or two to check on older threads and it would be a pain to lose track of what I've already read.

Is there a way to partially delete history for a site? Some XML or other editable file?
have you checked safe mode?
it should be better confirming that this is not add-on related thing first, before touching history.

then, history is stored in places.sqlite file in your profile.
(Reporter)

Comment 5

7 months ago
Confirming that slow link coloring on refresh happens even in safe mode.
(Reporter)

Comment 6

7 months ago
If it would help anyone, I could export and attach the site history give the appropriate SQL.
thanks!
Moving to Places component.
Component: Untriaged → Places
Flags: needinfo?(nmanole)
Product: Firefox → Toolkit
I can confirm this bug on FF 49.0 (safe mode on).

Comment 9

5 months ago
The visited query is quite simple, but clearly we need to run one query per url, so if the page has many, it may take a bit more. It shouldn't be that slow though, that makes me think the disk was strangely busy or waiting for something.
Do you have an antivirus and would you mind checking if disabling it temporarily helps?

could you please tell us some more information regarding your profiles:
1. size of places.sqlite in the profile folder
2. does vacuuming the db with this add-on help? https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/
3. attach a log from your about:support
4. system specs (cpu, ram, disk type)

This may just end up being the same as bug 484928. There's a patch there but it had unresolved issues.
There's clearly space for improvement here, but we should first measure whether this is a common problem around.
Status: UNCONFIRMED → NEW
Depends on: 484928
Ever confirmed: true
Priority: -- → P3
Also, once 50 will be released (in a couple weeks) please report if this improves, there's a change there that may improve things a little bit.
(Reporter)

Comment 11

5 months ago
Created attachment 8808046 [details]
contents of about:support
(Reporter)

Comment 12

5 months ago
My places.sqlite was 61,440KB before vacuuming, 51,200 after. Slow coloring still happens.

Attached contents of about:support.

Processor	Intel(R) Core(TM) i7 CPU       Q 820  @ 1.73GHz, 1734 Mhz, 4 Core(s), 8 Logical Processor(s)
Installed Physical Memory (RAM)	16.0 GB
Available Physical Memory	9.56 GB
Hitachi GST Travelstar 7K500 HTS725050A9A364 (0A72335) 500GB 7200 RPM 16MB Cache SATA 3.0Gb/s partitioned in 2:

C:
Size	149.18 GB (160,184,229,888 bytes)
Free Space	40.41 GB (43,394,150,400 bytes)

D:
Size	315.66 GB (338,939,604,992 bytes)
Free Space	81.99 GB (88,035,905,536 bytes)

Firefox installed on C:

I'll report on 50, once out.
(Reporter)

Comment 13

4 months ago
Links seem to be refreshing quickly with 50. I consider this resolved.
I suspect bug 889561 helped by reducing size of the db and changing the url string search to an integer search + comparison... Hard to be 100% sure, but the result sounds good. marking as WFM cause it's hard to confirm the underlying fix.

bug 484928 will stay open for further improvements.
Feel free to reopen if the issue should come back.
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Depends on: 889561
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.