Specify a different APP_ID for fennec webapp runtime

VERIFIED FIXED in Firefox 16



Firefox for Android
Web Apps
5 years ago
5 years ago


(Reporter: Pedro Alves, Unassigned)


Firefox 17

Firefox Tracking Flags

(firefox16 fixed, firefox17 verified, fennec+)



(1 attachment)



5 years ago
Currently webapp runtime on fennec is indistinguishable from fennec, as it uses the same APP_ID.

Would be useful to give it a different one. Desktop webapp rt uses 'webapprt@mozilla.com'. Something like 'webapprtmobile@mozilla.com' would be nice (or whatever unique app_id)
(Minor correction: the desktop runtime actually uses the app ID webapprt@mozilla.org.)

cc:ing some of the Fennec folks who are working on the Android runtime.

Note that we discussed whether or not to distinguish runtime reports from Firefox reports on desktop, and we ultimately decided to distinguish them, even if some (perhaps most) will have identical root causes, because others will not, and the relative frequencies of even identical crashes will vary because of the different usage patterns of apps vs. the web as a whole (so topcrashes will differ).

Changing our minds about that is relatively easy, provided the runtime has a different app ID, because we can reprocess reports and munge products together (or vice-versa).  But the runtime does need to have a different app ID for us to have the option to distinguish its reports, hence this bug.
As long as Fennec _is_ the webapp runtime on Android, we can't change the core APP ID.

We might be able to play with the URL sent to the blocklist (or whatever URL metrics uses) to substitute a different APP ID.

Comment 3

5 years ago
From the metrics end, changing the app_id to something unique or changing the blocklist ping to something like: 


would be exactly the same

(is url is a modification of the one extracted from firefox desktop: https://addons.mozilla.org/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/%TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/ , I'm assuming fennec is the same)


5 years ago
tracking-fennec: --- → ?
status-firefox16: --- → affected
tracking-fennec: ? → +


5 years ago
Priority: -- → P1
Created attachment 645596 [details] [diff] [review]

Sending this review to mfinkle because I want to make sure he's ok with it.
Attachment #645596 - Flags: review?(mark.finkle)


5 years ago
OS: Mac OS X → Android
Hardware: x86 → ARM
Comment on attachment 645596 [details] [diff] [review]

This method should work OK. I worry that "mobile" is too general. This is the webapprt for Android only. Other mobile platforms will have different runtimes.

Maybe I am over thinking things.

nit: 'webapprtmobile@mozilla.com' -> "webapprt-mobile@mozilla.org"

* add the '-'
* 'com" -> 'org'
* use double quotes
Attachment #645596 - Flags: review?(mark.finkle) → review+

Comment 6

5 years ago
That would mean that we'd also need to add both an ADI mechanism for the mobile webapp runtime in separate, just as we did for desktop, and that we'd also need to add it as a separate product in Socorro for monitoring crashes.
Comment on attachment 645596 [details] [diff] [review]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): No regression
User impact if declined: none
Testing completed (on m-c, etc.): landed on mc today 8/3
Risk to taking this patch (and alternatives if risky): very low risk. Just changes a pref on webapps. needed to push webapps in 16
String or UUID changes made by this patch: None.
Attachment #645596 - Flags: approval-mozilla-aurora?
So has this been changed in crash reporting?

And if so, what AppID is it reporting?

Daniel, will metrics have any ADU for Fennec WebRT?


5 years ago
Duplicate of this bug: 764955
I'm not familiar with the crash reporter code. An mxr search showed %APP_ID% only being used for addon updates (addons are disabled in webapps) and in the addon blocklist. I'll have to dig more to know for sure that one of them is being used for crash reporting somehow (unless you can point me to some code?)
s/ADU/ADI.  ADI is Mozilla's measure of Active Daily Installs.  Currently, this measurement is derived from the add-on blocklist check requests that come in to addons.mozilla.org.  The Crash Stats team (Socorro) uses the ADI to calculate the ratio of crash reports to install-base.

If the Fennec WebappRT doesn't make a blocklist check, we will not have any visibility into the number of active daily installs for it.

If this is the case, we need to escalate this issue and figure out quickly how to fix or work around it.

Comment 13

5 years ago
(In reply to Wesley Johnston (:wesj) from comment #11)
> I'm not familiar with the crash reporter code.

Bug 745980 apparently implemented crash reporting for the desktop WebRT, I guess that code can help.
(In reply to Daniel Einspanjer :dre [:deinspanjer] from comment #12)
> If the Fennec WebappRT doesn't make a blocklist check, we will not have any
> visibility into the number of active daily installs for it.

I need to double check that disabling addons doesn't disable the blocklist check, but we're currently doing the same thing that desktop does, so I imagine we're fine.

Comment 15

5 years ago
I can confirm that we are getting the correct information from desktop

Comment 16

5 years ago
We gave the name 'WebappRuntime' to the desktop webapprt ('webapprt@mozilla.com')

So we're going to give the name 'WebappRuntime Mobile' to this new one ('webapprt-mobile@mozilla.org') unless someone has a better suggestion.


Comment 17

5 years ago
Remove the whitespace, please. It's easier for the socorro team
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 17
Comment on attachment 645596 [details] [diff] [review]

Just for WebRT so shouldn't affect Fennec itself - approving for Aurora.
Attachment #645596 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+


5 years ago
status-firefox17: --- → verified
Keywords: checkin-needed


5 years ago
Blocks: 780972
Keywords: checkin-needed
status-firefox16: affected → fixed
You need to log in before you can comment on or make changes to this bug.