URL home screen shortcut is not working

VERIFIED FIXED in Firefox 33

Status

()

Firefox for Android
General
VERIFIED FIXED
3 years ago
a year ago

People

(Reporter: CristinaM, Assigned: nalexander)

Tracking

({regression})

Trunk
Firefox 33
ARM
Android
regression
Points:
---

Firefox Tracking Flags

(firefox32 unaffected, firefox33 verified, fennec33+)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

3 years ago
Environment:
Build: Firefox for Android 33.0a2 (2014-06-30)
Device: Nexus 4 (Android 4.4.2)

Steps to reproduce:
1.Go to www.mozilla.org/en-US/;
2.Long tap on URL bar and choose Add to home screen;
3.Tap on home button;
4.On home screen the URL shortcut is displayed, tap on it.

Expected result:
The page is opened and displayed correctly.

Actual result:
"App isn't installed." toast notification is displayed and the page is not opened.

Notes: Not reproducible on tablets.
Please work on a regression range.
tracking-fennec: --- → ?
Flags: needinfo?(cristina.madaras)
Keywords: regressionwindow-wanted
(Assignee)

Comment 2

3 years ago
Hmm, this is the kind of fall-out that I worried about with Bug 929865.  We should get a window around that ticket as a first approximation.

Updated

3 years ago
Flags: needinfo?(cristina.madaras)
Keywords: regression
QA Contact: cristina.madaras
(Reporter)

Comment 3

3 years ago
Regression window:
Last good revision: a19e0434ea52 (2014-06-25)
First bad revision: 464bca437658 (2014-06-26)

Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a19e0434ea52&tochange=464bca437658
Keywords: regressionwindow-wanted
Regression window agrees.
Blocks: 929865
(Assignee)

Comment 5

3 years ago
Status update: I've dug into this, and the issue is Bug 929865.  I didn't include the appropriate intent-filters for the org.mozilla.fennec/org.mozilla.gecko.BrowserApp activity.  Everything appears to work fine if we just duplicate the intent-filter set from the org.mozilla.fennec/.App activity-alias, but I want to investigate which filters we might prune from .App, and I'm finding what I think is some dead code.  Will continue working on this tomorrow.

Updated

3 years ago
status-firefox32: --- → unaffected
status-firefox33: --- → affected
(Assignee)

Comment 6

3 years ago
bnicholson, rnewman: I'd like a second persective and hopefully a concurring opinion.

When we started Bug 929865, pretty much everything used org.mozilla.fennec/.App.  Right before that ticket landed, we had gained stuff using org.mozilla.fennec/org.mozilla.gecko.BrowserApp.  What that means is that the slightly dated patches added only intent-filters to .App, which means org.mozilla.gecko.BrowserApp is a little naked, leading to bustage like the above.

My perspective is that we should duplicate the intent-filters from .App to org.mozilla.gecko.BrowserApp, possibly pruning some from .App (to try to avoid duplicate launchers, duplicate share intents, etc).  There is a risk of busting some existing intents (like above), or duplicating some thing that Android exposes to other apps.  (It would suck to see "Fennec" twice in the list of "Open with..." options.)

Do you have strong opinions?  Do you think we back out instead?
Flags: needinfo?(rnewman)
Flags: needinfo?(bnicholson)
Assignee: nobody → nalexander
tracking-fennec: ? → 33+
(In reply to Nick Alexander :nalexander from comment #6)

> My perspective is that we should duplicate the intent-filters from .App to
> org.mozilla.gecko.BrowserApp, possibly pruning some from .App (to try to
> avoid duplicate launchers, duplicate share intents, etc).

My reading of how activity-alias works:

* If old launcher targets are pointing at the old name, and the alias has all of the old intent-filters, then we're golden.

* If we're now creating launcher targets pointing at the new name, doing the same stuff, then the new name needs the same intent-filters as the old. That seems to be this bug.

* I don't know if Android strips out aliases if both the alias and the target match an intent. It shouldn't matter if we launch directly by name (as Comment 0 implies), but we can test this.


So that's one solution: both BrowserApp and .App should have the same intent filters. As you note, we can minimize those on .App to only support the legacy launcher icons.

The alternative is for us to still create .App launcher icons. :/
Flags: needinfo?(rnewman)
(In reply to Nick Alexander :nalexander from comment #6)
> My perspective is that we should duplicate the intent-filters from .App to
> org.mozilla.gecko.BrowserApp

Yeah, this aligns with our original decision back in bug 929865 (see attached IRC discussion: https://bug929865.bugzilla.mozilla.org/attachment.cgi?id=822520). I was against changing these intents from App->BrowserApp at first, but I think it makes sense to start deprecating App by duplicating these intent filters if we want to eventually remove them.
Flags: needinfo?(bnicholson)
(Assignee)

Comment 9

3 years ago
Created attachment 8456525 [details] [diff] [review]
Part 1: Add intent-filters to non-aliased .Webapp activity. r=bnicholson

Tested locally with:

adb shell am start -a org.mozilla.gecko.WEBAPP -n org.mozilla.fennec_nalexander/.Webapp -d http://penguinpop.justplaymobile.com/penguinpop.webapp

and

adb shell am start -a org.mozilla.gecko.WEBAPP -n org.mozilla.fennec_nalexander/org.mozilla.gecko.Webapp -d http://penguinpop.justplaymobile.com/penguinpop.webapp

Both log the expected message in the dispatcher:

W GeckoWebappImpl(12501)      no package name; treating as legacy shortcut

Both fail with:

E GeckoConsole(12177)         Error getting pref for application/x-web-app-manifest+json.

I verified that this behaviour happens with the Nightly of June 24, 2014 --
the one right before the patch that introduced this regression.

Finally, I confirmed this failing behaviour with two distinct hosted manifests.
Attachment #8456525 - Flags: review?(bnicholson)
(Assignee)

Comment 10

3 years ago
Created attachment 8456526 [details] [diff] [review]
Part 2: Add intent-filters to non-aliased BrowserApp activity. r=bnicholson

This very carefully adds all the .App intent-filters, but removes the
categories (DEFAULT and/or BROWSEABLE).  If the categories remain, two
Fennec icons are shown in some contexts by the Android system, one for
each action.  (DEFAULT actions are shown for generic file actions, like
opening in "My files"; BROWSEABLE actions are shown for opening links
from browser.)

Tested by:

* creating and launching a home screen shortcut; (the presenting issue)
* verifying no double launcher icons on the home screen;
* verifying no double icon on "Share via" from another Firefox;
* verifying no double icon on tapping ".html" file from "My files".
Attachment #8456526 - Flags: review?(bnicholson)
(Assignee)

Comment 11

3 years ago
bnicholson: I was very conservative here.  We're at the end of a cycle, so I don't feel comfortable monkeying more than the minimum with .App versus BrowserApp.  We can move filters away from the .App alias and onto BrowserApp at the beginning of the 34 cycle, when we have time to address problems.
Status: NEW → ASSIGNED
Attachment #8456525 - Flags: review?(bnicholson) → review+
(Assignee)

Comment 12

3 years ago
Created attachment 8457684 [details] [diff] [review]
Export gecko.{WebApp,BrowserApp}. r=bnicholson

This allows explicit intents from outside of the App.  Tested locally by:

* creating and launching a home screen shortcut; (the presenting issue)

* trying a an "old style" webapp home screen launch, like:

adb shell am start -a org.mozilla.gecko.WEBAPP -n org.mozilla.fennec_nalexander/.Webapp -d http://penguinpop.justplaymobile.com/penguinpop.webapp

and

adb shell am start -a org.mozilla.gecko.WEBAPP -n org.mozilla.fennec_nalexander/org.mozilla.gecko.Webapp -d http://penguinpop.justplaymobile.com/penguinpop.webapp

Both log the expected message in the dispatcher:

W GeckoWebappImpl(12501)      no package name; treating as legacy shortcut

Both fail with:

E GeckoConsole(12177)         Error getting pref for application/x-web-app-manifest+json.

I verified that this behaviour happens with the Nightly of June 24, 2014 -- the
one right before the patch that introduced this regression.
Attachment #8456525 - Attachment is obsolete: true
Attachment #8456526 - Attachment is obsolete: true
Attachment #8456526 - Flags: review?(bnicholson)
Attachment #8457684 - Flags: review?(bnicholson)
(Assignee)

Comment 13

3 years ago
bnicholson and I determined in IRC that the intent-filters added by the previous patch series were not in fact necessary (and added some risk, since we could have duplicate icons, etc).  The intent-filters were flipping the exported flag, which is enough for out-of-App explicit intent launching.
Comment on attachment 8457684 [details] [diff] [review]
Export gecko.{WebApp,BrowserApp}. r=bnicholson

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

Makes a lot more sense!
Attachment #8457684 - Flags: review?(bnicholson) → review+
(Assignee)

Comment 15

3 years ago
https://hg.mozilla.org/integration/fx-team/rev/67ae43394166
https://hg.mozilla.org/mozilla-central/rev/67ae43394166
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 33

Updated

3 years ago
Flags: needinfo?(cristina.madaras)
Keywords: verifyme
(Reporter)

Comment 17

3 years ago
Verified as fixed on:
Build: Firefox for Android 33.0a1 (2014-07-20)
Device: Motorola Razr (Android 4.0.4)
Status: RESOLVED → VERIFIED
status-firefox33: affected → verified
Flags: needinfo?(cristina.madaras)
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.