Closed Bug 932641 Opened 6 years ago Closed 6 years ago

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

Categories

(Firefox for Android :: General, defect)

All
Android
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 28
Tracking Status
firefox26 --- unaffected
firefox27 + verified
firefox28 --- verified
fennec 27+ ---

People

(Reporter: nschubach, Assigned: wesj)

References

Details

(Keywords: regression, reproducible)

Attachments

(1 file)

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.
E/GeckoConsole( 8911): [JavaScript Error: "HelperApps.openUriInApp is not a function" {file: "chrome://browser/content/browser.js" line: 7754}]

Regression from bug 780379
Blocks: 780379
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
Hardware: Other → All
Summary: long press 'open with' does not open app → Regression: long press 'open with' does not open app
Assignee: nobody → wjohnston
tracking-fennec: ? → 27+
Attached patch PatchSplinter Review
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...
Attachment #825702 - Flags: review?(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.
Attachment #825702 - Flags: review?(margaret.leibovic) → review+
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.
Attachment #825702 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/7b7cf033f986
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(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.
Target Milestone: --- → Firefox 28
Keywords: verifyme
Attachment #825702 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.