Cannot update collections icon

VERIFIED FIXED in 5.0.9

Status

defect
P2
major
VERIFIED FIXED
10 years ago
4 years ago

People

(Reporter: cbaker, Assigned: wenzel)

Tracking

unspecified
5.0.9

Details

Attachments

(1 attachment, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 ImageShackToolbar/5.2.1
Build Identifier: 

After clicking "Replace Icon", browsing the path and clicking "Update Collection" button, original icon is displayed.  I can delete the icon ok, but re-uploading a new icon still displays the original one.

Reproducible: Always
How long have you waited after uploading the new icon?
When I first created the collection, I uploaded an icon.  It "took" immediately.  I then realized that the icon did not have a transparent background. So I created a new icon and uploaded it (with a different name) about 30 or 45 minutes later.  The original icon displayed after the update.  I tried it again once or twice inside of about five minutes.  Finally, I deleted the original.  Immediately after updating, it was gone (as it should have been).  Tried uploading the new icon again, but the original showed up.

It's been at least an hour since updating and the original still appears on the collection page (https://addons.mozilla.org/en-US/firefox/collection/backups) *and* the manage collections page.
I can confirm this: It seems, the icons are cached forever. We need to add something to the URL like we do for the add-on icons and previews.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → 5.0.9
Assignee: nobody → fwenzel
Status: NEW → ASSIGNED
OS: Windows Vista → All
Hardware: x86 → All
Posted patch Patch, rev. 1 (obsolete) — Splinter Review
Another instance of the "cake caching suckage" issue: After updating the icon, it is not reloaded, but the existing icon is cached under the new URL. By disabling caching on postback when the icon is changed, this should be fixed.
Attachment #393515 - Flags: review?(clouserw)
Comment on attachment 393515 [details] [diff] [review]
Patch, rev. 1

Ummm.  You're adding a height and width?
Attachment #393515 - Flags: review?(clouserw) → review-
Crap, wrong patch :-/
Posted patch Patch, rev. 2Splinter Review
Now even more (read: at all) applicable to this bug.
Attachment #393515 - Attachment is obsolete: true
Attachment #393641 - Flags: review?(clouserw)
Without some kind of randomness, won't it just cache /updated too?  So if someone updates twice in a row it'll cache the original and the first but nothing following?
(In reply to comment #8)
> Without some kind of randomness, won't it just cache /updated too?  So if
> someone updates twice in a row it'll cache the original and the first but
> nothing following?

The randomness (not really) is before the /updated: It's the timestamp of modifying the picture. That was present all along. What /updated does is it causes the model not to use caching (cf. the image controller code) and actually fetch the data from the database. The problem before was that in spite of the timestamp being present, cake served the same picture again without even looking at the database, so the old picture was mistakenly served under the new name, then cached by the netscaler.
Comment on attachment 393641 [details] [diff] [review]
Patch, rev. 2

well sir!
Attachment #393641 - Flags: review?(clouserw) → review+
r49076. I really hope this still works once it hits production ;)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: push-needed
Resolution: --- → FIXED
Verified FIXED on https://preview.addons.mozilla.org/en-US/firefox/collections/edit/f0db3bdb-43b7-5838-7281-6bdb86010cca (uploaded, replaced, replaced again).

/me crosses fingers too
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.