Closed
Bug 1397174
Opened 8 years ago
Closed 7 years ago
Fix scale issue for icons like AdaptiveIconDrawable in Android O
Categories
(Firefox for Android Graveyard :: General, defect, P3)
Tracking
(firefox58 wontfix, firefox59 wontfix, firefox60 wontfix, firefox61 wontfix, firefox62 wontfix, firefox63 wontfix, firefox64 verified)
VERIFIED
FIXED
Firefox 64
People
(Reporter: cnevinchen, Assigned: vlad.baicu)
References
Details
(Keywords: good-first-bug, Whiteboard: --do_not_change--[priority:high])
Attachments
(3 files)
Follow up for bug 1372040
| Reporter | ||
Updated•8 years ago
|
Summary: Make Fennec support AdaptiveIconDrawable in Android O → Fix scale issue for icons like AdaptiveIconDrawable in Android O
| Reporter | ||
Updated•8 years ago
|
Priority: -- → P2
| Reporter | ||
Updated•8 years ago
|
Keywords: good-first-bug
[triage] Awkward and embarrassing, but non-critical.
Priority: P2 → P3
Assignee: cnevinchen → nobody
Updated•8 years ago
|
Comment 6•8 years ago
|
||
Maybe this is something that should be looked at again after the API 26 migration has been finished?
status-firefox61:
--- → affected
status-firefox62:
--- → affected
status-firefox63:
--- → affected
Flags: needinfo?(sdaswani)
OS: Unspecified → Android
Hardware: Unspecified → All
Vlad would https://bugzilla.mozilla.org/show_bug.cgi?id=1349522 solve this issue too?
Flags: needinfo?(sdaswani) → needinfo?(vlad.baicu)
Comment 9•8 years ago
|
||
No, bug 1349522 is about providing an adaptive icon ourselves.
This bug is about the fact that if other apps use adaptive icons, we don't resize those icons correctly when displaying them within Firefox.
Flags: needinfo?(vlad.baicu)
Comment 10•7 years ago
|
||
Also being reported in the Firefox subreddit: https://www.reddit.com/r/firefox/comments/96eoao/firefox_you_feeling_okay/
Comment 11•7 years ago
|
||
It's getting close to November and once Google's target API requirements are in force, even more other apps will presumably use adaptive icons.
status-firefox64:
--- → affected
Flags: needinfo?(sdaswani)
Comment 12•7 years ago
|
||
Bram, can you provide new Adaptive icons?
Flags: needinfo?(sdaswani) → needinfo?(bram)
Comment 13•7 years ago
|
||
This isn't about our own icons, this is about fixing our share menu so it doesn't look like https://i.imgur.com/lKlSOCL.jpg or https://i.redd.it/rsh3xrjia6011.jpg because *other* apps are using adaptive icons and we don't handle it properly. I'd do this myself, but I don't have a phone with Oreo and doing things blindly without being able to properly test was already painful enough for the updater notifications, so I won't attempt anything here.
Flags: needinfo?(bram) → needinfo?(sdaswani)
Comment 14•7 years ago
|
||
Sorry Jan, my bad. I will have the Softvision devs take a look.
Flags: needinfo?(sdaswani)
Whiteboard: --do_not_change--[priority:high]
Comment 15•7 years ago
|
||
Comment 16•7 years ago
|
||
Comment 17•7 years ago
|
||
Hi Jan, one of the easiest way to ensure adaptive icon compatibility (for now, and in the future) is by invoking the system native share dialogue: attachment 9010460 [details].
The other way to solve this problem is by resizing our icons from 72dp down to 36dp: attachment 9010461 [details].
What do you think?
Flags: needinfo?(jh+bugzilla)
Comment 18•7 years ago
|
||
I think one reason for using our own share menu is that we want to order share targets by usage frequency - compare also how the top two share targets are also accessible directly from the top-level menu. There also might be other customisations included that wouldn't be possible with the system share dialogue, so I think we should just fix our own menu to explicitly resize icons to our target size.
This size isn't always 36dp by the way - when invoked from the main menu, we use both smaller font and icon size than when sharing from a context menu. I didn't look into the reason for this difference, though.
Flags: needinfo?(jh+bugzilla)
Comment 19•7 years ago
|
||
(In reply to Jan Henning [:JanH] from comment #18)
> […] I think we should just fix our own menu to
> explicitly resize icons to our target size.
Sounds like a plan. I figure that there were very good reasons why we use our own implementation.
> This size isn't always 36dp by the way - when invoked from the main menu, we
> use both smaller font and icon size than when sharing from a context menu. I
> didn't look into the reason for this difference, though.
Yeah. I saw that. When sharing from the main menu, the icon size is 24dp. In fact, all the icons there are consistent.
So, we shouldn’t change the main menu at all. The only icon size that we need make consistent are the ones inside the long-press context menu.
Does this give you enough information to fix this bug?
Flags: needinfo?(jh+bugzilla)
Comment 20•7 years ago
|
||
Possibly, but I'd still prefer someone who can more easily test this to do it.
Flags: needinfo?(jh+bugzilla)
| Assignee | ||
Updated•7 years ago
|
Assignee: nobody → vlad.baicu
| Assignee | ||
Comment 22•7 years ago
|
||
Added a check for AdaptiveIconDrawables and a way to resize them to our specific size.
| Assignee | ||
Updated•7 years ago
|
Keywords: checkin-needed
Comment 23•7 years ago
|
||
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/57994656668d
Fix scale issue for AdaptiveIconDrawables. r=JanH
Keywords: checkin-needed
Comment 24•7 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Updated•7 years ago
|
Flags: qe-verify+
Updated•7 years ago
|
Comment 26•7 years ago
|
||
Verified as fixed with Google Pixel (Android 9.0), on Beta 64.0b11.
Updated•5 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•