890671 - Timing issue causes addon icon not to load

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Add-on Manager, defect)

Description

[Mark Capella [:capella]]

In some cases, commonly on FF start (system busy?), when an addon loads a menu item with an icon, then adds a second item to it / uses it as a parent, the logic that converts the original item to a submenu occurs before the original icon is loaded in it's background thread, causing it to be dropped, until a subsequent disable / enable, or browser start / stop reloads the menu.

The (implied) "else" portion of this statement occurs when either there was no original icon, or this situation is encountered:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/BrowserApp.java#1415

Because this hasn't completed yet:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/BrowserApp.java#1438

Comment 1

[Mark Capella [:capella]]

Attachment: Sample addon with spurious icon loss

Comment 2

[Sriram Ramasubramanian [:sriram]]

Attachment: Patch

It's not good to depend on MenuItem. But we know the item id. It's better to have it and find the menu item with that.

Comment 3

[Sriram Ramasubramanian [:sriram]]

Attachment: Patch

This is same as old patch. Moves the setIcon() to the UI thread.

Comment 4

[Sriram Ramasubramanian [:sriram]]

Attachment: Patch: Rebased

A series of inbound closures followed by refactoring of Bitmap loading made the patch fail. The new patch is so simple (as all the bits around it are factored out), but essentially the same approach.

Comment 5

[Sriram Ramasubramanian [:sriram]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9ee18bf7ee04

Comment 6

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/9ee18bf7ee04