Closed
Bug 598670
Opened 14 years ago
Closed 14 years ago
Personas preview image should be small (200px across)
Categories
(addons.mozilla.org Graveyard :: Public Pages, defect)
addons.mozilla.org Graveyard
Public Pages
Tracking
(Not tracked)
VERIFIED
FIXED
5.12.5
People
(Reporter: whimboo, Assigned: jbalogh)
References
()
Details
Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100922 Firefox/4.0b7pre
In some cases we display the full screenshot which breaks the details pane. I have already mentioned that on bug 593217 comment 1.
By using a Firefox Cup theme the screenshot (or thumbnail) extends the normal width we allow for a thumbnail. All the text gets shifted out of the default view. See attachment 476556 [details].
Not sure if we should block because we do not know how many add-ons are affected by this bug. Lets Dave decide.
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 1•14 years ago
|
||
Dave, we are letting you decide! :)
Comment 2•14 years ago
|
||
The problem here is that AMO delivers us a preview image for personas but for some reason it is sending very large previews (680px across). The preview image is meant to be a small thumbnail of the persona, getpersonas.com only sends 200px previews.
Component: Add-ons Manager → Public Pages
Product: Toolkit → addons.mozilla.org
QA Contact: add-ons.manager → web-ui
Summary: Full screenshots should not be displayed in details view → Personas preview image should be small (200px across)
Version: Trunk → unspecified
Comment 3•14 years ago
|
||
We've got 3 sizes:
- The size on search results pages (https://addons.mozilla.org/en-US/firefox/search/?q=asdf&cat=all&lver=any&pid=1&sort=&pp=20&lup=&advanced=)
- The full size (https://addons.mozilla.org/en-US/firefox/addon/29725/)
- And the small sizes at the bottom of the full size page. Sounds like you'd like the small size at the bottom of the page?
How are we delivering this to you?
Comment 4•14 years ago
|
||
The url is passed in the previewURL property of the JSON blob in the data-browsertheme attribute of the theme div on the page (try saying that after a few drinks)
Comment 5•14 years ago
|
||
Oh, it looks like the tiny images are just served off getpersonas and the search result size is us just trimming the image with CSS.
Comment 6•14 years ago
|
||
This code hasn't changed in a long time. Is this a change on your end?
Updated•14 years ago
|
Target Milestone: --- → 5.12.1
Comment 7•14 years ago
|
||
We have changed where the image is displayed, but it wouldn't look good on 3.6 for it to be that large either.
Comment 8•14 years ago
|
||
potch: any idea what's going on here? any ramifications if we change it?
Comment 9•14 years ago
|
||
What is the priority on this bug for the client team?
Comment 10•14 years ago
|
||
I think we're going to end up having to work around this separately anyway so I'd put it at a low priority from our side now
blocking2.0: ? → ---
Updated•14 years ago
|
Target Milestone: 5.12.1 → 4.x (triaged)
Comment 12•14 years ago
|
||
Any chance I can convince someone to make this a high priority? The workaround we have (bug 602059) is going to make the preview look a lot uglier than if it were just the smaller size (see bug 616634 for details).
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → jbalogh
Target Milestone: 4.x (triaged) → 5.12.5
Assignee | ||
Comment 13•14 years ago
|
||
(In reply to bug 616634 comment #2)
> In addition to preview_large.jpg (680x100 - too big) and preview_small.jpg
> (32x32 - too small), there's also preview.jpg (200x67 - just right). Using
> preview.jpg turns out to be better than just scaling preview_large.jpg, since
> it cuts of the left side of the image (the right side is the important area).
>
> So there's a few options:
> 1. Get AMO to send us the location of preview.jpg (in a thumbnailURL property)
> 2. Assume preview.jpg will always be in the same path as preview_large.jpg, and
> alter the URL we have for preview_large.jpg
> 3. Resize preview_large.jpg, without care for the aspect ratio (won't look that
> good)
It seems like we could put preview.jpg into previewURL instead of thumbnailURL as (1) proposes. AMO doesn't care what's in previewURL, and getpersonas.com is using preview.jpg in previewURL, so I assume all clients will happily handle the smaller previewURL.
Comment 14•14 years ago
|
||
(In reply to comment #13)
> It seems like we could put preview.jpg into previewURL instead of thumbnailURL
> as (1) proposes. AMO doesn't care what's in previewURL, and getpersonas.com is
> using preview.jpg in previewURL, so I assume all clients will happily handle
> the smaller previewURL.
Oh, yes - that's the conclusion that was reached in later comments in that bug.
Assignee | ||
Comment 15•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 16•14 years ago
|
||
whimboo, can you please check if this is fixed in allizom? Thanks!
Reporter | ||
Comment 17•14 years ago
|
||
Installing the given Persona from allizom, correctly shows up a smaller thumbnail, while installing it from AMO still shows the large version. Given that I assume we can call this bug as verified fixed.
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•