932641 - Regression: long press 'open with' does not open app

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Nick Schubach]

User Agent: Mozilla/5.0 (Android; Tablet; rv:28.0) Gecko/28.0 Firefox/28.0 (Nightly/Aurora)
Build ID: 20131029030201

Steps to reproduce:

Long pressing an application gives the option to open with another app based on the link type.  Images should open Gallery, YouTube links should open the YouTube app.  These no longer work.


Actual results:

Firefox does nothing with the link.


Expected results:

It should send the link to the other application to handle it the way it did.

Comment 1

[Aaron Train [:aaronmt]]

E/GeckoConsole( 8911): [JavaScript Error: "HelperApps.openUriInApp is not a function" {file: "chrome://browser/content/browser.js" line: 7754}]

Regression from bug 780379

Comment 2

[Wesley Johnston (:wesj)]

Attachment: Patch

Missed this in API changes I guess.

I spent awhile trying to write a test today, but I think the test framework will have to either dynamically register a handler (BroadcastReceiver?) or have something in its manifest. Neither seems to work though. I need something like that for FilePickers as well, so I'll keep looking...

Comment 3

[:Margaret Leibovic]

Comment on attachment 825702 [details] [diff] [review]
Patch

Looks good to me. I double-checked that we're not using openUriInApp anywhere else.

Comment 4

[Wesley Johnston (:wesj)]

https://hg.mozilla.org/integration/fx-team/rev/7b7cf033f986

Comment 5

[Wesley Johnston (:wesj)]

Comment on attachment 825702 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 780379
User impact if declined: Open in app option doesn't work anymore
Testing completed (on m-c, etc.): Tested locally. Landing now!
Risk to taking this patch (and alternatives if risky): Very low risk. Just changing an API name.
String or IDL/UUID changes made by this patch: None.

Comment 6

[Jim Mathies [:jimm]]

https://hg.mozilla.org/mozilla-central/rev/7b7cf033f986

Comment 7

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

(In reply to Wesley Johnston (:wesj) from comment #2)

> I spent awhile trying to write a test today, but I think the test framework
> will have to either dynamically register a handler (BroadcastReceiver?) or
> have something in its manifest. Neither seems to work though. I need
> something like that for FilePickers as well, so I'll keep looking...

Can we make mock XPCOM objects instead and just manually fire some of the HelperApp and ExternalApps methods? We don't really need to open real applications. We only need to see that the internal code is not buggy.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6383a9b61c9a