Closed Bug 993698 Opened 9 years ago Closed 8 years ago

Page action icon from chrome:// URL is scaled down


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



(firefox44 fixed, fennec+)

Firefox 44
Tracking Status
firefox44 --- fixed
fennec + ---


(Reporter: Margaret, Assigned: vivek)




(1 file)

I made an add-on that puts icons in a /skin directory, and when I try using those icons with the page actions API, they are scaled down.

All the places we use the pageactions API ourselves in fennec, we use drawable:// URLs, so we haven't run into this issue in the product, but we should figure out why these are inconsistent.
I traced this issue back to GeckoJarReader, but I couldn't find anything obviously wrong in there. Is it possible this could be an issue with NativeZip?
tracking-fennec: --- → ?
Flags: needinfo?(wjohnston)
Assignee: nobody → wjohnston
tracking-fennec: ? → 30+
Wes - Feel free to dupe or "block" on other bugs you have open related to this
I decided to use data: URIs as a workaround for my home feeds add-on, so it isn't super critical to get this done for 30 (although this is pretty bad for add-on authors).
I tried to reproduce this using things in our own theme directory and couldn't see it. I used things like:


The reader icon was small, but its a small icon. The rest fit or were scaled down to fit. I wonder if digging into these nested add-on jar's is causing GeckoJarReader some confusion...
Flags: needinfo?(wjohnston)
I just realized this is probably dupe of bug 959896. But that was when I was trying to load an image in our own browser code, not through an add-on.

Sounds like we have some jar issues...
tracking-fennec: 30+ → +
filter on [mass-p5]
Priority: -- → P5
Blocks: 1162107
I have no idea whats up here. Margaret was talking about making these multi-resolution problems better in general. Is this still relevant?
Flags: needinfo?(margaret.leibovic)
Assignee: wjohnston → nobody
I'm not sure if this is still an issue, but I think add-ons mostly use data: URIs to work around problems like this, so we just might now be noticing it.

Redirecting NI to Sebastian, who's recently looked into how we load images from gecko.
Flags: needinfo?(margaret.leibovic) → needinfo?(s.kaspari)
Even though I recently dug into GeckoJarReader in an other bug I'm not exactly sure what's going on here. My first assumption is that Android might try to resize the bitmap to match the density of the device (because we are not loading from a drawable-*dpi folder).
Flags: needinfo?(s.kaspari)
Bug 993698 Update target density while reading BitmapDrawable from stream r?sebastian
Attachment #8673185 - Flags: review?(s.kaspari)
Attachment #8673185 - Flags: feedback?(margaret.leibovic)
Assignee: nobody → vivekb.balakrishnan

::: mobile/android/base/util/
(Diff revision 1)
> +                // In fact it discards the resources

Well that's not intuitive at all! I know we've had bugs in the past where we didn't properly pass in resources to the BitmapDrawable construtor, but this is another level of confusion. Nice find.

Without testing this out myself, this seems like a sane fix to me.
Attachment #8673185 - Flags: feedback?(margaret.leibovic) → feedback+
Comment on attachment 8673185 [details]
MozReview Request: Bug 993698 Update target density while reading BitmapDrawable from stream r?sebastian

LGTM. I tested this patch on my devices.
Attachment #8673185 - Flags: review?(s.kaspari) → review+
Bug 993698 Update target density while reading BitmapDrawable from stream r=sebastian
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.