945375 - When choosing share from the three-dot-menu, Firefox crashes.

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Michael Cooper [:mythmon]]

I downloaded Nightly today to try out the new share feature. On every webpage I have tried, pressing the sync menu item (from the three dots menu), crashes Nightly, giving the "Unfortunately, Nightly has stopped."

Sharing from the long-press menu works fine.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

What device? Any crash ids? about:crashes in the address bar

Comment 2

[Michael Cooper [:mythmon]]

Galaxy S4 (Tmobile), running Cyanogenmod 10.1.

about:crashes says "No crash reports have been submitted."

Could logcat output be useful? I should be able to get that if it could be useful.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Mike Cooper [:mythmon] from comment #2)

> Could logcat output be useful? I should be able to get that if it could be
> useful.

Yes. That would be very useful.

Comment 4

[Michael Cooper [:mythmon]]

Attachment: nightly-share.log

I did this:

$ adb logcat -c
$ adb logcat | tee nightly-share.log

Then I went to my phone, started Firefox, clicked on one of the homepage tiles, clicked the 3dots, then clicked share. It crashed, as usual.

Looking through the logcat, I definitely see some interesting things, but I don't really know enough about the internals to point to anything interesting.

Comment 5

[Aaron Train [:aaronmt]]

E/GeckoAppShell( 7051): java.lang.NullPointerException
E/GeckoAppShell( 7051): 	at android.view.ViewGroup.addView(ViewGroup.java:3318)
E/GeckoAppShell( 7051): 	at android.view.ViewGroup.addView(ViewGroup.java:3301)
E/GeckoAppShell( 7051): 	at org.mozilla.gecko.GeckoApp.showMenu(GeckoApp.java:379)
E/GeckoAppShell( 7051): 	at org.mozilla.gecko.menu.GeckoMenu.showMenu(GeckoMenu.java:259)
E/GeckoAppShell( 7051): 	at org.mozilla.gecko.menu.GeckoMenu.handleMenuItemClick(GeckoMenu.java:443)
E/GeckoAppShell( 7051): 	at org.mozilla.gecko.menu.GeckoMenu.onItemClick(GeckoMenu.java:423)

Comment 6

[Aaron Train [:aaronmt]]

I'm hitting this on Nightly (11/03, en-US build) on my LG Nexus 4. Crash-stats is piddling around trying to submit my report so I can attach a signature.

Comment 8

[Lucas Rocha (:lucasr)]

This seems like a regression from bug 936756.

Comment 9

[Lucas Rocha (:lucasr)]

Attachment: Unconditionally return mSubmenu in GeckoMenuItem.getSubMenu() (r=rnewman)

Comment 10

[Lucas Rocha (:lucasr)]

Comment on attachment 8342395 [details] [diff] [review]
Unconditionally return mSubmenu in GeckoMenuItem.getSubMenu() (r=rnewman)

Menuitems with an associated ActionProvider depend on mSubMenu too. See:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/menu/GeckoMenu.java#434

Although the intent behind the original change to getSubMenu() seems correct. But this approach would only work if the ActionProvider actually held its own reference to its submenu of something. If that was the case, we'd have something like:

public getSubMenu() {
    if (mActionProvider != null && mActionProvider.hasSubMenu()) {
        return mActionProvider.getSubMenu();
    }

    return mSubMenu;
}

Comment 11

[Richard Newman [:rnewman]]

Comment on attachment 8342395 [details] [diff] [review]
Unconditionally return mSubmenu in GeckoMenuItem.getSubMenu() (r=rnewman)

Review of attachment 8342395 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, I was seeing problems if I called mActionProvider.getSubMenu -- it was returning a thing that actually wasn't a usable submenu (e.g., for clearing).

Comment 12

[Lucas Rocha (:lucasr)]

https://hg.mozilla.org/integration/fx-team/rev/2bd207736d7b

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2bd207736d7b