Closed Bug 1057247 Opened 10 years ago Closed 10 years ago

Increase favicon retry time

Categories

(Firefox for Android Graveyard :: Favicon Handling, defect)

All
Android
defect
Not set
normal

Tracking

(firefox33 verified, firefox34 verified, firefox35 verified)

VERIFIED FIXED
Firefox 35
Tracking Status
firefox33 --- verified
firefox34 --- verified
firefox35 --- verified

People

(Reporter: m_kato, Assigned: rnewman)

References

Details

Attachments

(1 file)

Now, retry failed favicon's time (FAILURE_RETRY_MILLISECONDS) is hard-coded as 20 min. A carrier requests us this timer becomes customizable by preference (about:config).
s/carrier/mobile operator/
Pref customizability here would be non-trivial, but I'd be very open to bumping this value to one much higher. What value does the carrier favor?
Hardware: ARM → All
Flags: needinfo?(m_kato)
(In reply to Richard Newman [:rnewman] from comment #2) > Pref customizability here would be non-trivial, but I'd be very open to > bumping this value to one much higher. What value does the carrier favor? How hard would it be to add a sue of PrefsHelper into the code? http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/PrefsHelper.java
(In reply to Mark Finkle (:mfinkle) from comment #3) > How hard would it be to add a use of PrefsHelper into the code? Not hard, but it would couple the favicon cache to Gecko via an event listener, which I'm not keen to do without a strong motivation. If we were going that route, I'd try to sculpt a simple sibling of PrefsHelper that didn't incur a round-trip, taking an approach similar to the one we're taking for proxy handling: cache the value on the Java side, and update it when it changes in Gecko. We would benefit from that work in several places. In this case I don't think it's particularly necessary: the 20-minute default is arbitrary, we really have no idea if it offers value in the real world, and even if it does, I'm not super concerned if we don't retry a failed fetch for an hour (or six) instead of 20 minutes.
I am asking this mobile operator what number is better...
Flags: needinfo?(m_kato)
Flags: needinfo?(m_kato)
(In reply to Richard Newman [:rnewman] from comment #4) > (In reply to Mark Finkle (:mfinkle) from comment #3) > > > How hard would it be to add a use of PrefsHelper into the code? > > Not hard, but it would couple the favicon cache to Gecko via an event > listener, which I'm not keen to do without a strong motivation. > > If we were going that route, I'd try to sculpt a simple sibling of > PrefsHelper that didn't incur a round-trip, taking an approach similar to > the one we're taking for proxy handling: cache the value on the Java side, > and update it when it changes in Gecko. We would benefit from that work in > several places. > > In this case I don't think it's particularly necessary: the 20-minute > default is arbitrary, we really have no idea if it offers value in the real > world, and even if it does, I'm not super concerned if we don't retry a > failed fetch for an hour (or six) instead of 20 minutes. I talk with vendor today. They are happy to change to 1 hour. Could you change to 1 hour?
Flags: needinfo?(m_kato)
Code change is trivial, but signoff always worthwhile.
Attachment #8490805 - Flags: review?(mark.finkle)
Assignee: nobody → rnewman
Status: NEW → ASSIGNED
Comment on attachment 8490805 [details] [diff] [review] Increase favicon refetch time to one hour. >diff --git a/mobile/android/base/GeckoApp.java b/mobile/android/base/GeckoApp.java >+ Log.i("GeckoXXX", "storeAndNotify: " + osLocale); >- >+ Log.i("GeckoXXX", "storeAndNotify: last = " + lastOSLocale); >+ Log.i("GeckoXXX", "storeAndNotify: tag = " + osLanguageTag); Remove these (Probably part of another patch) >diff --git a/mobile/android/base/favicons/cache/FaviconCache.java b/mobile/android/base/favicons/cache/FaviconCache.java >+ // Retry failed favicons after one hour. >+ public static final long FAILURE_RETRY_MILLISECONDS = 1000 * 60 * 60; Did we ever apply science to the retry? If it was arbitrary, why not go higher? 4 hours?
Attachment #8490805 - Flags: review?(mark.finkle) → review+
Heh, I knew I should have made sure I had qreffed first. No, we didn't apply science. Yes, I'd be happy to go higher.
Comment on attachment 8490805 [details] [diff] [review] Increase favicon refetch time to one hour. Approval Request Comment [Feature/regressing bug #]: Old design decision. [User impact if declined]: Fennec will re-fetch failed favicons every 20 minutes. Partner request. [Describe test coverage new/current, TBPL]: None. [Risks and why]: Zero risk. Changes a constant. [String/UUID change made/needed]: None.
Attachment #8490805 - Flags: approval-mozilla-beta?
Attachment #8490805 - Flags: approval-mozilla-aurora?
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Attachment #8490805 - Flags: approval-mozilla-beta?
Attachment #8490805 - Flags: approval-mozilla-beta+
Attachment #8490805 - Flags: approval-mozilla-aurora?
Attachment #8490805 - Flags: approval-mozilla-aurora+
I see the change in the code. As I understand we did not implement a new pref ( as seen in the patch too) so I will set this to VERIFIED FIXED.
Summary: Customizable favicon retry time → Increase favicon retry time
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: