NotificationHandler sending bad intents to gecko

RESOLVED FIXED

Status

()

Firefox for Android
General
RESOLVED FIXED
5 years ago
9 months ago

People

(Reporter: wesj, Assigned: wesj)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(firefox16+ unaffected, firefox17+ fixed, firefox18 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Margaret has been seeing some strange behavior with notifications potentially. i.e. a "This url must be opened by an app Alert prompt appears" with nothing to do. I recently changed their behavior slightly in bug 781061. It sounds like we are trying to open the dat url sent to Fennec rather than The intent being sent to Fennec is what I expect:

I/GeckoNotificationHandler(25156): startActivity with intent: Action='org.mozilla.gecko.ACTION_ALERT_CALLBACK appName='org.mozilla.fennec.App'
I/ActivityManager(  308): START {act=org.mozilla.gecko.ACTION_ALERT_CALLBACK dat=alert:/-297100515?name=update-app&app=org.mozilla.fennec.App&cookie= flg=0x10000000 cmp=org.mozilla.fennec/.App u=0} from pid 25156

I'm guessing that we are trying to open this dat term when the Notification is tapped and Gecko isn't running. Will need to confirm that though.
(Assignee)

Comment 1

5 years ago
Created attachment 656127 [details] [diff] [review]
Patch

I hate having to do this this way. If Gecko is running and you tap a Notification, we end up calling onNewIntent which has all this code to do special things with different intents. If not (we used to just bail, but with my recent change we start Gecko now and) we call onCreate which just assumes any url's it finds in an intent are real urls.

I'd really like onCreate to call into the same code that onNewIntent does. Unfortunately, onNewIntent fires intents to start loads whereas onCreate just sends the url to gecko with startup params. i.e. untangling the two is not being easy. Since this is on beta right now, I'd like to put up this patch for there and work on a better one for Nightly?
Assignee: nobody → wjohnston
Attachment #656127 - Flags: review?(mark.finkle)
Attachment #656127 - Flags: review?(mark.finkle) → review+

Comment 2

5 years ago
Oh, I didn't see you file this. I filed bug 786394. Is that a dupe now?
(Assignee)

Comment 3

5 years ago
Yeah. I'm still not sure what your webapp bug was though....
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 786394
(Assignee)

Comment 4

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/1052d9e756f8
(Assignee)

Comment 5

5 years ago
Comment on attachment 656127 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 781061
User impact if declined: Clicking system Notifications after Fennec has closed will lead to strange messages and blank tabs. In webapps it can lead to unusable situations (i.e. a blank tab you can't get out of, but webapps are turned off on beta).
Testing completed (on m-c, etc.): Landed on mc 8-29
Risk to taking this patch (and alternatives if risky): This is the low risk alternative. We could change 781061 so that we don't launch fennec in these situations again, but that requires some Android trickery that is non-trivial on Aurora. We could revert 781061 entirely on Beta since webapps are disabled there.
String or UUID changes made by this patch: None.
Attachment #656127 - Flags: approval-mozilla-beta?
Attachment #656127 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

5 years ago
status-firefox16: --- → affected
status-firefox17: --- → affected
status-firefox18: --- → affected
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?

Updated

5 years ago
tracking-firefox16: ? → +
tracking-firefox17: ? → +

Updated

5 years ago
Attachment #656127 - Flags: approval-mozilla-beta?
Attachment #656127 - Flags: approval-mozilla-beta-
Attachment #656127 - Flags: approval-mozilla-aurora?
Attachment #656127 - Flags: approval-mozilla-aurora+

Comment 6

5 years ago
Let's track the backout of bug 781061 there.
Resolution: DUPLICATE → FIXED

Updated

5 years ago
Duplicate of this bug: 786394
https://hg.mozilla.org/mozilla-central/rev/1052d9e756f8

Updated

5 years ago
status-firefox18: affected → fixed
(Assignee)

Updated

5 years ago
Duplicate of this bug: 787425

Updated

5 years ago
status-firefox16: affected → wontfix

Updated

5 years ago
status-firefox16: wontfix → unaffected

Updated

5 years ago
Duplicate of this bug: 789347
Aurora checkin?
(Assignee)

Comment 12

5 years ago
Sorry for the delay:
https://hg.mozilla.org/releases/mozilla-aurora/rev/d164700915f8

Updated

5 years ago
status-firefox17: affected → fixed
Did the patch land on Aurora 09/13?

I installed the Aurora build mentioned above, I checked for updates and I quit app after the notification was triggered. Clearing the notifications will auto-open Aurora.
I can reproduce this issue on the Aurora from 09/14. When notification update was triggered, I quit Aurora and then I cleared the update notification from Android Notification Bar. The result was auto-app relaunch. Reopening bug

--
Device: Galaxy Note
OS: Android 4.0.4
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 15

5 years ago
Ahh. The app relaunching is a different bug than the one fixed here (trying to open a bogus URL). The other piece was fixed in bug 786599, but not pushed to Aurora yet (doing that now). Thanks for catching that. Reclosing.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.