980124 - LINE app not showing up on firefoxos phones

Status: VERIFIED FIXED

(Marketplace Graveyard :: Consumer Pages, defect)

Description

[krupa raj[:krupa]]

firefoxos 1.4

steps to reproduce:
1. Launch marketplace firefox prod on your firefoxos phone
2. search for LINE app

expected behavior:
LINE app shows up on the homepage since it is featured and shows up in the search results

actual behavior:
LINE app shows up on desktop but not on firefoxos phones

LINE app is available in all regions: https://marketplace.firefox.com/developers/app/line/payments/

ashes:
ID:83a14
ID: a15e3

profile: http://cl.ly/image/1V102H3X0609

dupe from rob's recent fix to implement buchets/device filters?

Comment 1

[Christopher Van Wiemeersch [:cvan]]

In [7]: dict(FeatureProfile.from_signature('7d7ba9fe6f6d.47.4'))
Out[7]: 
{'activity': True,
 'alarm': False,
 'apps': True,
 'archive': False,
 'audio': True,
 'battery': True,
 'bluetooth': False,
 'camera': True,
 'contacts': True,
 'device_storage': True,
 'fm': False,
 'fullscreen': True,
 'gamepad': False,
 'geolocation': True,
 'idle': False,
 'indexeddb': True,
 'light_events': True,
 'mic': True,
 'mp3': True,
 'network_info': True,
 'network_info_multiple': True,
 'network_stats': True,
 'notification': True,
 'orientation': True,
 'packaged_apps': True,
 'pay': True,
 'pointer_lock': True,
 'proximity': True,
 'push': False,
 'qhd': True,
 'quota': False,
 'screen_capture': False,
 'sms': False,
 'speech_rec': False,
 'speech_syn': True,
 'systemxhr': True,
 'tcpsocket': True,
 'thirdparty_keyboard_support': False,
 'time_clock': False,
 'touch': True,
 'vibrate': True,
 'video_h264': True,
 'video_webm': True,
 'webaudio': True,
 'webrtc_data': True,
 'webrtc_media': True,
 'webrtc_peer': True}


http://f.cl.ly/items/033j0L2v0e123N2b3n0q/Screen%20Shot%202014-03-05%20at%204.36.26%20PM.png

You have all of the correct feature requirements of this app except "push" notifications. Is "push" supposed to be supported on these devices (1.3)?

Comment 2

[Bill Walker [:bwalker] [@wfwalker]]

Yes, push is on these devices, and the LINE app worked on these devices when we demoed it at MWC.

Comment 3

[Christopher Van Wiemeersch [:cvan]]

https://github.com/mozilla/fireplace/blob/master/hearth/media/js/buckets.js#L70

I presume `'mozPush' in navigator || 'push' in navigator`, yes?

Comment 4

[Bill Walker [:bwalker] [@wfwalker]]

(In reply to Christopher Van Wiemeersch [:cvan] from comment #3)
> https://github.com/mozilla/fireplace/blob/master/hearth/media/js/buckets.
> js#L70
> 
> I presume `'mozPush' in navigator || 'push' in navigator`, yes?

Reading https://wiki.mozilla.org/WebAPI/SimplePush I would say you are correct

Comment 5

[Christopher Van Wiemeersch [:cvan]]

Can you run http://jsbin.com/vesuluse/1 please and tell me what it says?

Comment 6

[Didem Ersoz [:didem]]

(In reply to Christopher Van Wiemeersch [:cvan] from comment #5)
> Can you run http://jsbin.com/vesuluse/1 please and tell me what it says?

I am using a Geeksphone with 1.3, I ran the line you provided above, and it says: 

"navigator.mozPush unsupported"
"navigator.push unsupported"

The app for me was working without an issue earlier today. Then i uninstalled and tried to re-install it, and it disappeared from the Marketplace. My contact at LINE has received his ZTE Open with 1.3 today. Around the same time I was having the issue, he tried installing the LINE app and faced the same problem, the app wasn't on the marketplace.

Comment 7

[Christopher Van Wiemeersch [:cvan]]

We exclude any app that requires a permission that is unsupported on the mobile device from which the user is installing the app.

Based on https://developer.mozilla.org/en-US/docs/WebAPI/Simple_Push and https://hacks.mozilla.org/2013/07/dont-miss-out-on-the-real-time-fun-use-firefox-os-push-notifications/ it would appear that I'm calling `navigator.push` correctly.

What I'm discovering appears to be the same issue as bug 859554 and bug 838614 comment 10.

This may be a platform regression, or it's possible it never worked. Regardless of the permissions that the Marketplace has (and it is a privileged app but we don't ask for `push` permissions in our manifest), checking for the presence of `'push' in navigator` should return `true`. `navigator.push` does not have to be truthy or do anything, but it should not never ever `undefined` (that's what bug 859554 and related bugs are all about).

Because `'push' in navigator` is returning `false`, the Marketplace thinks that push notifications are not supported. Marketplace is not making a mistake here; it's trusting the value of `navigator.push` (or a lack thereof) to do feature detection. The fix here is to fix the platform (or to have LINE temporarily remove "Push" from their feature requirements until this is fixed). Until then, nobody can accurately detect the existence of push notifications.

I'm CC'ing Jason and Fabrice for any background knowledge they may be able to share.

Comment 8

[Andrew Williamson [:eviljeff]]

is bug 979932 connected to this?  It appears to have similar symptoms but the opposite - LINE does show but the #1 and #2 most popular apps (line being #3) don't.

Comment 9

[Mathieu Pillard [:mat]]

Like bug 979932 it started appearing because we fixed a bug that was preventing us to send the feature profile to the API (bug 975063). However in this case, the feature detection for 'push' used to work, but it's broken in 1.3.

Comment 10

[Jason Smith [:jsmith]]

Nikhil - Can you weigh in here on what's causing push to not be detected via the navigator object here?

Comment 11

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

'push' will not show up because marketplace or marketplace running in the browser don't have the requisite permission ('push').

\

Comment 12

[Christopher Van Wiemeersch [:cvan]]

But it should still exist in navigator. It should just be null.

Comment 13

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

Bug 920840 prevents WebIDL implemented APIs from ever returning null. Maybe we should involve some standards and webcompat guys and arrive at a consensus?

a) Feature not available - undefined.
b) Feature available but not allowed for this app - null.
c) Feature available and allowed - the interface.

Pinging sicking.

Comment 14

[Wil Clouser [:clouserw]]

Thus far we've been inconsistent about detection (even going so far as fixing some bugs and wontfixing others asking for the same thing for different APIs).  I've sent an email to b2g-release-drivers@ and dev-webapi@ to attempt to solve this once and for all (can't link to the mail because it hasn't been moderated yet).  I'll paste the text, since it's relevant, but I'd like to keep the discussion to the email lists.

Regarding this particular bug, we have a patch to disable compatibility detection on the marketplace which we'll push out today as a compromise to fix the severe app installation dropoff we're seeing.

Email text:

> Hi folks,
> 
> One of the requirements for the Marketplace is to, by default, offer only
> compatible apps to visitors.  Since we're on the web, this essentially comes
> down to tracking what permissions apps request and comparing that to client
> side capability detection (eg. "This app requires a camera to function - does
> the device browsing the marketplace have a camera?").
> 
> In order to do the client side comparison, we've been using pretty common JS
> detection[1], things like `'vibrate' in navigator`.  When the check returns
> undefined we know the platform doesn't support that feature and don't show the
> app.  When the check returns null or a value we know the platform does support
> the feature (even if the Marketplace doesn't have access to it) and we show the
> app.
> 
> There is some confusion and debate about this[2] suggesting that returning null
> is not expected behavior in JS.  Bugs have been filed to standardize this[3]
> but some are fixed[4], some are wontfixed[5], some have been open for almost a
> year[6], and new APIs fall either way based on who writes them and we've ended
> up with a mix of detectable and undetectable APIs.
> 
> We pushed out an updated list of API detection earlier this week and several of
> our most popular apps suffered severe installation dropoffs as devices reported
> that they couldn't install the apps because they didn't have the required
> capabilities (even though they actually could run the app).
> 
> Temporarily, the Marketplace will disable capability detection since the
> inconsistent results showed such a sharp decline in installs, but this means
> that users will be able to install incompatible apps and as the number of
> devices using the Marketplace grows, so will the user frustration around this.
> This will become more pronounced as Android (Q1) and Desktop (Q2) Marketplaces
> are advertised this year.
> 
> The longer we delay a solution to this the bigger the problem will get.  How
> can the Marketplace (a privileged and not certified app) fulfill the detection
> requirement both for already released versions of FxOS and future versions?
> 
> Thanks,
> 
> Wil
> 
> [1] https://github.com/mozilla/fireplace/blob/master/hearth/media/js/buckets.js
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=838614
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=859554
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=859601
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=874263
> [6] https://bugzil.la/859610,859612,859614,859615

Comment 15

[Wil Clouser [:clouserw]]

This push has gone out and this should be fixed.  closing for verification.

Comment 16

[krupa raj[:krupa]]

LINE now shows up on my b2g phone. Thanks for the quick fix.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

There's been a lot of confusion about when and how APIs show up. I've put my thoughts in bug 900241 comment 52. If there's anything that's unclear please do ask over there.