Telemetry for Permissions Notifications

RESOLVED FIXED in Firefox 43

Status

()

defect
P1
normal
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: Paolo, Assigned: Paolo)

Tracking

Trunk
Firefox 44
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox43+ fixed, firefox44 fixed)

Details

(Whiteboard: [fxprivacy])

User Story

*** GENERAL GOALS ***

We're working on a redesign of permission notifications. We believe the new design would reduce accidental dismissals and improve the overall interaction, but we would like to validate that it actually does.

*** HIGH LEVEL QUESTIONS ANSWERED ***

- Which types of UI interactions are the most common? Any surprises?
- How many permissions are granted and how many denied through these notifications (thus excluding manual changes)?
- How many notifications are dismissed without an explicit choice?
- Do reopened notifications actually show an intention to take an action?
- Are there specific notifications that show a different interaction pattern than the average of all notifications? Any surprises?
- With the new notification design, do the above results change?

*** TELEMETRY ***

Note that we don't record telemetry in private windows, only because the available actions can be different from regular mode. The main difference is that all of the persistent permission options like "Always remember" aren't there, so they really need to be handled separately to avoid skewing results. For notifications with the same choices, there would be no reason not to record in private windows as well, but it's just simpler to use the same check for everything.

=== POPUP_NOTIFICATION_STATS ===

A general keyed histogram recording usage of notifications generated by "PopupNotifications.jsm". The key is the notification ID, an argument specified by the callers of the "show" method. An additional key named "(all)" is recorded regardless of notification ID.

We record statistics for reopened notifications separately, because we want to understand if an intention to interact with the notification actually results in a different permission choice. Anything from 0 to 19 applies to the first time the notification is shown. Anything from 20 to 29 applies to reopened notifications. Each value is recorded at most once per notification.

   0: Notification offered ("show" method called).
      Incremented if a new prompt with the same ID replaces an existing one.
   1: Main action actually triggered (requires the security delay).
   2: Secondary action actually triggered.
   3: Third possible action actually triggered.
   4: Fourth possible action actually triggered.
   5: Dismissed by clicking elsewhere on the page or in the system.
   6: Dismissed by switching to a different tab.
   7: Dismissed by clicking on the "X" icon.
   8: Dismissed by clicking the "Not now" submenu option.
  10: The submenu dropdown arrow has been clicked
      (not necessarily resulting in an action).
  11: The 'Learn More' link for the specific notification has been clicked.

  20: Notification reopened by the user after it was dismissed.
  21: Same as 1 (main action), but on a reopened notification.
  22: ...same as 2, but on a reopened notification.
  23: ...and so on.

=== POPUP_NOTIFICATION_MAIN_ACTION_MS ===

Milliseconds between the time the notification was first offered (and also displayed on the screen, unless differently specified in the "show" method) and the time the main action was triggered. The key is the notification ID, and we also record the "(all)" key.

This is the total timing of the main action since the notification was
created, even if the notification was dismissed in the meantime.

We record 40 buckets between 100 ms and 10 minutes. Simulation:

https://telemetry.mozilla.org/histogram-simulator/#low=100&high=600000&n_buckets=40&kind=exponential&generate=log-normal

Anything less than 500 ms indicates that the action was not executed the first time, because we incurred in the security delay.

=== POPUP_NOTIFICATION_DISMISSAL_MS ===

Milliseconds between the time the notification was first offered and the time it was first dismissed, unless the main action was triggered. The key is the notification ID, and we also record the "(all)" key.

We record 50 buckets between 200 ms and 20 seconds. Simulation:

https://telemetry.mozilla.org/histogram-simulator/#low=200&high=20000&n_buckets=50&kind=exponential&generate=log-normal

*** DURATION OF COLLECTION ***

Collection of the POPUP_NOTIFICATION_STATS histogram is opt-out in release channels and expires in Firefox 50 (bug 1228671).

Collection of the other histograms is opt-in in release channels and expires in Firefox 52 (bug 1257222).

Most data should stop being collected when the work on Permissions Notification has stabilized or when Firefox 52 leaves the Beta channel sometime in 2017, whichever comes first.

*** RESPONSIBLE TEAM ***

Firefox Privacy and Security:

https://wiki.mozilla.org/Firefox/privacyandsecurity

Attachments

(1 attachment)

We're thinking of using a keyed histogram to record telemetry for permission notifications, where the key is the type of permission granted.

We may consider having an extra key to record results for the sum of all permission notifications, for comparison with specific ones, if this feature is not already provided by the telemetry dashboards.

Notifications shown in Private Browsing Mode are excluded from telemetry.

Each enumerated histogram could have buckets similar to these:
1. Notification offered
2. "X" dismissal in notification
3. User clicks off of hanger/ hits ESC
4. User clicks learn more link
5. Ignore: User leaves/closes page 
6. The drop down arrow for the select menu
7. Anchor icon to re-open notification after it's been closed
8. Default action
9. "Not now"
10. first secondary
11. Second secondary
12. Third secondary
13. ...
Flags: qe-verify?
Whiteboard: [fxprivacy]
Priority: -- → P3
Flags: qe-verify? → qe-verify-
Priority: P3 → P1
Assignee: nobody → paolo.mozmail
Status: NEW → ASSIGNED
Iteration: --- → 44.2 - Oct 19
Most of the messages handled by PopupNotifications.jsm are permission notifications, and just a few are not.

We could instrument PopupNotifications.jsm and ensure we create a unique key for the messages we care about. That might require some of the callers to provide a unique key, if we cannot already distinguish by anchor type for example. If the caller does not provide a key, we use a heuristic to determine it, with the understanding that it might not be unique.

There might be extra reports for other notifications like add-on installation, that we can just ignore for the purposes of the telemetry.

Matt, do you think we could go with this approach? I think I can ask Brian for the code review.
Flags: needinfo?(MattN+bmo)
Why not instrument CPP_showPrompt? That is specific to permissions. Is there any permission prompt that doesn't go through it? If so, it should probably be changed.
Flags: needinfo?(MattN+bmo)
Re-reading some of the things wanted to be collected, it probably does make sense to do this in PopupNotifications instead. I think it's fine to record this in PopupNotification for all consumers (though we may also capture extension doorhangers). We already have IDs for notifications which are probably good enough.
Iteration: 44.2 - Oct 19 → 44.3 - Nov 2
User Story: (updated)
Bug 1207089 - Telemetry for permission notifications. r=bgrins
Vlad, please see the User Story field and the bug description for a summary of the telemetry we're adding for permission notifications. There's also a proof of concept patch attached. Do you have any questions related to this data collection?

Do we need to request feedback from you again once the final patch is ready?
Flags: needinfo?(vladan.bugzilla)
(In reply to :Paolo Amadini from comment #0)
> Notifications shown in Private Browsing Mode are excluded from telemetry.

This was initially part of the original feature description, but I don't remember if there was a specific reason for this or it was just a reminder that we needed to discuss the issue.

In general, permission notifications can be requested by web content regardless of whether the site is opened in Private Browsing Mode or not. The permission notification itself does not contain information about whether a particular website has been visited, or whether Private Browsing Mode was used at all. I also believe we already collect data such as whether a specific feature of the web platform is used, regardless of the context in which the web page is opened?

I'd like to understand if we can collect average data regardless of window type here.
Flags: needinfo?(ehsan)
https://reviewboard.mozilla.org/r/22639/#review20133

::: toolkit/components/telemetry/Histograms.json:5668
(Diff revision 1)
> -    "n_buckets": "80 + 1",
> +    "description": "(Bug 1207089) Usage of popup notifications, keyed by ID (0 = Offered, 11 = Main action)"

why only 0 and 11?
(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #7)
> why only 0 and 11?

It's just a proof of concept, in the final patch I'll assign values based on what makes more sense. For example, 10 + action index could be a criteria for actions.

I've reserved values up to 20 on this enumerated histogram though we're only using 12 or so of them initially. This is as suggested on the telemetry page, because the upper limit cannot be changed once defined.
Sorry, I jumped into the code right away.

> Do we need to request feedback from you again once the final patch is ready?

Yes.

I think you should reconsider accumulating a value each time a counter is incremented. Otherwise, the resulting dashboard histogram will be misleading. For example 1 will be massively over-represented compared to higher values. .

These are my suggestions for how to define histograms for each question, note that I don't fully understand the requirements so apologies for any bad suggestions.

> - Which types of UI interactions are the most common? Any surprises?

What's a "type of UI interaction"? is it the list from comment 0? A keyed enum histogram would work well, where the key is the permission requested and each bucket is a different type of response (clicked on Grant, clicked on X, etc)

> - How many permissions are granted and how many denied through these notifications (thus excluding manual changes)?

You can get this from the histogram above.

> - How many notifications are dismissed without an explicit choice?

Also covered by the first histogram.

> - Are there specific notifications that show a different interaction pattern than the average of all notifications? Any surprises?

If the key is the permission requested and you're trying to understand if there are different interaction patterns for different permissions requested, the first histogram is sufficient and you can answer this by using the Telemetry dashboard.

> - With the new notification design, do the above results change?

I think this would still be the first histogram, you would just compare the histogram across different buildIDs.
Flags: needinfo?(vladan.bugzilla)
(In reply to :Paolo Amadini from comment #6)
> (In reply to :Paolo Amadini from comment #0)
> > Notifications shown in Private Browsing Mode are excluded from telemetry.
> 
> This was initially part of the original feature description, but I don't
> remember if there was a specific reason for this or it was just a reminder
> that we needed to discuss the issue.

One reason was because the available actions differ between PB and regular mode. The main being that all of the persistent permission options e.g. Always/Never remember aren't there are so they really need to be handled separately to avoid skewing results. Rather than bucket them separately it was decided we can just not record in PB.
Also, we can't bucket them separately or it will leak that the user used PB which is against our current PB standards.
(In reply to :Paolo Amadini from comment #6)
> (In reply to :Paolo Amadini from comment #0)
> > Notifications shown in Private Browsing Mode are excluded from telemetry.
> 
> This was initially part of the original feature description, but I don't
> remember if there was a specific reason for this or it was just a reminder
> that we needed to discuss the issue.
> 
> In general, permission notifications can be requested by web content
> regardless of whether the site is opened in Private Browsing Mode or not.
> The permission notification itself does not contain information about
> whether a particular website has been visited, or whether Private Browsing
> Mode was used at all. I also believe we already collect data such as whether
> a specific feature of the web platform is used, regardless of the context in
> which the web page is opened?
> 
> I'd like to understand if we can collect average data regardless of window
> type here.

I don't see why we can't.  This doesn't mean that we'll be logging the URLs of the sites that create these permission notifications or something like that, right?
Flags: needinfo?(ehsan)
I just noticed we already have WARNING_GEOLOCATION_REQUEST_* telemetry which could be useful already to answer questions and should probably be replaced by this keyed approach.
Blocks: 1216963
(In reply to Matthew N. [:MattN] from comment #13)
> I just noticed we already have WARNING_GEOLOCATION_REQUEST_* telemetry which
> could be useful already to answer questions and should probably be replaced
> by this keyed approach.

Thanks! I've filed bug 1216963 to remove it, I think we can safely do that after the telemetry in this bug has landed and we start seeing consistent results in the dashboards.
(In reply to Matthew N. [:MattN] from comment #13)
> which could be useful already to answer questions

For the record, 1.95% of the geolocation prompts in Beta 42 result in an "Allow" interaction. It will definitely be useful to know if that's lower or higher than the average of all notifications.
(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #9)
> I think you should reconsider accumulating a value each time a counter is
> incremented. Otherwise, the resulting dashboard histogram will be
> misleading. For example 1 will be massively over-represented compared to
> higher values.

I'm not following, doesn't .add(key, 1) only add one to the "1" bucket, and .add(key, 11) only add one to the "11" bucket, so that if I compare the two on the dashboards, I get exactly the percentage of offered notifications that resulted in the main action being triggered?
I think I'll also call out that POPUP_NOTIFICATION_MAIN_ACTION_MS replaces a previous expired histogram and measures the time required for the user to parse and react to the notification. We can measure if this improves over time.

I've just realized we also want to understand the incidence of accidental dismissals, and we can do that by adding a POPUP_NOTIFICATION_DISMISSAL_MS histogram that's more fine-grained towards lower values. Any very low value can be considered an accidental dismissal, especially if it's lower than the average for POPUP_NOTIFICATION_MAIN_ACTION_MS.
User Story: (updated)
Brian, I still have to add most of the probes from the User Story field, but most of the logic is there and already provides really good data locally, so I'll post the patch for a preliminary review, because the module is a complicated one and review and testing might take some time.
Attachment #8676241 - Flags: feedback?(bgrinstead)
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

Forwarding the request to MattN who knows more about this
Attachment #8676241 - Flags: feedback?(bgrinstead) → feedback?(MattN+bmo)
User Story: (updated)
User Story: (updated)
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

Bug 1207089 - Telemetry for permission notifications. r=bgrins
Attachment #8676241 - Flags: feedback?(MattN+bmo) → review?(MattN+bmo)
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

Histogram definition should be complete, flagging for Telemetry data review.

The details are all in the User Story field, that is the one that appears just before the description in comment 0. The latter is now outdated and should be ignored.
Attachment #8676241 - Flags: feedback?(vladan.bugzilla)
User Story: (updated)
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

Bug 1207089 - Telemetry for permission notifications. r=MattN
Attachment #8676241 - Attachment description: MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=bgrins → MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN
Attachment #8676241 - Flags: feedback?(vladan.bugzilla)
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

Histogram definition should be complete, flagging for Telemetry data review.

The details are all in the User Story field, that is the one that appears just before the description in comment 0. The latter is now outdated and should be ignored.

(I've updated the code since I noticed the string in the histogram definition didn't match.)
Attachment #8676241 - Flags: feedback?(vladan.bugzilla)
https://reviewboard.mozilla.org/r/22639/#review20695

::: toolkit/components/telemetry/Histograms.json:5663
(Diff revision 3)
> -  "POPUP_NOTIFICATION_MAINACTION_TRIGGERED_MS": {
> +  "POPUP_NOTIFICATION_STATS": {

you should add alert_emails fields to all histograms

::: toolkit/components/telemetry/Histograms.json:5666
(Diff revision 3)
> -    "low": 25,
> +    "keyed": true,

how many keys are you expecting?

::: toolkit/components/telemetry/Histograms.json:5668
(Diff revision 3)
> -    "n_buckets": "80 + 1",
> +    "description": "(Bug 1207089) Usage of popup notifications, keyed by ID (0 = Offered, 1..4 = Action, 5 = Click outside, 6 = Leave page, 7 = Use 'X', 8 = Not now, 10 = Open submenu, 11 = Learn more. Add 20 if happened after reopen.)"

- I recommend splitting the stats for first-notification and notification-reopen into two different histograms. It's pretty clear they're two different measurements.
The two measurements can still be compared against each other just by opening each dashboard page in a separate Firefox window.
-If "0=Offered" is just the sum of all the first-notification buckets' samples, you don't need it

::: toolkit/components/telemetry/Histograms.json:5670
(Diff revision 3)
> +  "POPUP_NOTIFICATION_MAIN_ACTION_MS": {

nit: prefix these histograms with PERMISSIONS instead of POPUP, POPUP_NOTIFICATION is a bit misleading
Sorry for the slow review, I've been dealing with hiring/interview stuff the last two days. I should be able to get back to this today.
https://reviewboard.mozilla.org/r/22639/#review20695

> you should add alert_emails fields to all histograms

Feel free to add me if you aren't going to use a mailing list.

> nit: prefix these histograms with PERMISSIONS instead of POPUP, POPUP_NOTIFICATION is a bit misleading

This isn't specific to permissions, it's for all popup notification consumers (most of which are permission prompts) so I disagree.
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

https://reviewboard.mozilla.org/r/22639/#review20747

r=me assuming you did some sanity checks locally. Since there are many possibly edge cases due to PopupNotifications having a lot of options, we should probably test that any theories about how usage maps to telemetry can be reproduced in telemetry locally to ensure that the instrumentation aligns with our assumptions.

::: toolkit/components/telemetry/Histograms.json:5677
(Diff revision 3)
> +    "description": "(Bug 1207089) Time in ms between offering a popup notification and triggering the main action, keyed by ID"

Is it a new thing to put a bug number in the description? I've never seen that before.

::: toolkit/components/telemetry/Histograms.json:5686
(Diff revision 3)
> +    "description": "(Bug 1207089) Time in ms between offering a popup notification and dismissing it without an action, keyed by ID"

It would probably be good to be more explicit that this only counts the first dismissal as I had to check the code to be sure. Especially useful since that is different than POPUP_NOTIFICATION_MAIN_ACTION_MS.

This should also make it clear that it's measuring since the time it was visible, not just offered (to contrast with …MAIN_ACTION_MS)

::: toolkit/modules/PopupNotifications.jsm:76
(Diff revision 3)
> +  this.recordedTelemetryFirstTime = false;

This seems unused

::: toolkit/modules/PopupNotifications.jsm:167
(Diff revision 3)
> +    if (this.wasDismissed) {
> +      value += TELEMETRY_STAT_REOPENED_OFFSET;
> +    }

RE: vladan's suggestion. I only slightly prefer this current approach over two separate probes.

::: toolkit/modules/PopupNotifications.jsm:1111
(Diff revision 3)
> -  _onButtonCommand: function PopupNotifications_onButtonCommand(event) {
> +  _onButtonEvent: function PopupNotifications_onButtonEvent(event, type) {

Feel free to s/: function PopupNotifications_onButtonEvent// if you want

::: toolkit/modules/PopupNotifications.jsm:1140
(Diff revision 3)
> +    // Record the total timing of the main action since the notification was
> +    // created, even if the notification was dismissed in the meantime.
> +    let timeSinceCreated = this.window.performance.now() - notification.timeCreated;

I'm not sure why timeCreated is better than timeShown here. For most they will be basically the same  but for initially dismissed ones I'm not sure how counting the time before appearing is useful. Bill Maggs was interested in using this measurement to understand whether people actually read the text (which is really hard to map to a time anyways) but that would mean only measuring from when it's shown. I don't care too much since very few are dismissed initially thought it is more complexity.
Attachment #8676241 - Flags: review?(MattN+bmo) → review+
Attachment #8676241 - Flags: feedback?(vladan.bugzilla)
> Is it a new thing to put a bug number in the description? I've never seen that before.

Yes, this is brand new https://mail.mozilla.org/pipermail/fhr-dev/2015-October/000655.html
(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #24)
> how many keys are you expecting?

There will be one key per notification type, I think we have a dozen or so of them. Examples of keys are:

addon-progress
geolocation
indexedDB-permissions-prompt
pointerLock
webRTC-shareDevices

> - I recommend splitting the stats for first-notification and
> notification-reopen into two different histograms. It's pretty clear they're
> two different measurements.
> The two measurements can still be compared against each other just by
> opening each dashboard page in a separate Firefox window.

I concur with Matt in preferring a single histogram to look at (that's actually why I coded it this way in the first place). It would be simpler for us to read the dashboards this way, in particular because it would allow us to compare values at a glance with our reference level in bucket 0.

> -If "0=Offered" is just the sum of all the first-notification buckets'
> samples, you don't need it

It's the reference against which we're comparing the other values, but it's not the sum of the others because the interactions we're measuring are not mutually exclusive.
(In reply to Matthew N. [:MattN] from comment #27)
> r=me assuming you did some sanity checks locally. Since there are many
> possibly edge cases due to PopupNotifications having a lot of options, we
> should probably test that any theories about how usage maps to telemetry can
> be reproduced in telemetry locally to ensure that the instrumentation aligns
> with our assumptions.

Yeah, I did test locally with some key permission notifications like geolocation and microphone, and they measure what we want. I agree there are a lot of edge cases in how PopupNotifications.jsm could be used, if the data shows we missed something for particular custom notification types we want, we can easily fix the probes.

> ::: toolkit/modules/PopupNotifications.jsm:1140
> I'm not sure why timeCreated is better than timeShown here. For most they
> will be basically the same  but for initially dismissed ones I'm not sure
> how counting the time before appearing is useful. Bill Maggs was interested
> in using this measurement to understand whether people actually read the
> text (which is really hard to map to a time anyways) but that would mean
> only measuring from when it's shown. I don't care too much since very few
> are dismissed initially thought it is more complexity.

One is not better than the other, they are two different measurements that answer different questions. In this bug, we're trying to measure the total time it takes for the user to accomplish the task they want, for example from the time they clicked on a game and the time they started playing after accepting the pointer lock notification. Bill's question is different, so you may consider adding a probe in the specific bugs you've filed for push notifications measurements, it would be a simple addition after this bug landed.
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan
Attachment #8676241 - Attachment description: MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN → MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan
Attachment #8676241 - Flags: review?(vladan.bugzilla)
Attachment #8676241 - Flags: review?(vladan.bugzilla) → review+
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

https://reviewboard.mozilla.org/r/22639/#review21017
https://hg.mozilla.org/mozilla-central/rev/781512105804
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

We would like to get telemetry data on our Beta population this cycle, as we think it may be more representative of general usage. We're planning to start the Permission Notifications Redesign in Firefox 46 Nightly. If we uplift this patch, we'll have good data from Firefox 43 Beta by the time we start planning the most impactful permission notification changes in detail.

Approval Request Comment
[Feature/regressing bug #]: Permission Notifications Redesign
[User impact if declined]: This uplift is mainly aimed at obtaining good data for future decisions.
[Describe test coverage new/current, TreeHerder]: Landed on mozilla-central and already feeding Telemetry data on Aurora
[Risks and why]: Low risk, affected code is covered by regression tests
[String/UUID change made/needed]: None
Attachment #8676241 - Flags: approval-mozilla-beta?
I'd like to make sure the uplift request above is looked at.
Sure, don't worry, we were having a work week!
Comment on attachment 8676241 [details]
MozReview Request: Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan

Has tests coverage, liwill be helpful for the future, early in the cycle, taking it, two well known reviewers.
Should be in 43 beta 2.
Attachment #8676241 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
this does not apply cleanly to beta:

rafting 311398:781512105804 "Bug 1207089 - Telemetry for permission notifications. r=MattN,vladan"
merging toolkit/components/telemetry/Histograms.json
merging toolkit/content/widgets/notification.xml
merging toolkit/modules/PopupNotifications.jsm
warning: conflicts during merge.
merging toolkit/modules/PopupNotifications.jsm incomplete! (edit conflicts, then use 'hg resolve --mark')
abort: unresolved conflicts, can't continue
(use hg resolve and hg graft --continue)
Flags: needinfo?(paolo.mozmail)
I'll look into this and try to rebase on the beta repository tomorrow.
Applied cleanly on Beta with external merge tool, tested locally.
Flags: needinfo?(paolo.mozmail)
Blocks: 1257222
Blocks: 1228671
User Story: (updated)
Blocks: 1281190
You need to log in before you can comment on or make changes to this bug.