1409056 - Allow beta users to manually enable Report Site Issue button

Status: RESOLVED FIXED

(Web Compatibility :: Tooling & Investigations, enhancement, P1)

Description

[Mike Taylor [:miketaylr]]

Right now addon sources are only included for Dev Edition and Nightly, but we want to allow users who care to manually toggle a pref to get the Report Site Issue item.

http://searchfox.org/mozilla-central/source/browser/extensions/moz.build#28-29
http://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#5014-5018

Comment 1

[:Harald Kirschner :digitarald]

We are cautious enabling site reporting on Beta due to the volume of issues and keeping up a good SLA.

Landing it behind a pref will allow a staged rollout (and some other benefits eventually, like using it in experiments).

The proposed plan is to land this for 61 and to run a shield on beta, enabling reporting for an incremental amount of users while keeping an eye on report numbers and quality.

In conjunction, we should also land telemetry in how many clicks the feature gets to track some kind of conversion metric.

Comment 2

[Mike Taylor [:miketaylr]]

Hey Ryan, just to verify -- we don't have a define to land something as "not release" (aka, beta -> nightly), right? 

EARLY_BETA_OR_EARLIER exists, but maybe it's awkward or confusing to enable a feature that disappears partway through the beta cycle?

Comment 3

[Ryan VanderMeulen [:RyanVM]]

We do not have a release-only define other than by checking the update channel, though that has some caveats too.

Comment 4

[Mike Taylor [:miketaylr]]

Attachment: Bug 1409056. Allow webcompat-reporter addon to ride the trains.

(Note: this is still disabled by default for non-DevEdition and non-Nightly)

Review commit: https://reviewboard.mozilla.org/r/235102/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/235102/

Comment 5

[Mike Taylor [:miketaylr]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #3)
> We do not have a release-only define other than by checking the update
> channel, though that has some caveats too.

Thanks Ryan. I think it makes sense to just let the code ride the trains, as long as it's false by default for Beta and Release, and we let the Shield experiment do the flipping.

(Nothing should happen if the pref isn't true: https://searchfox.org/mozilla-central/source/browser/extensions/webcompat-reporter/bootstrap.js#43)

Comment 6

[Mike Taylor [:miketaylr]]

Comment on attachment 8966400 [details]
Bug 1409056. Allow webcompat-reporter addon to ride the trains.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/235102/diff/1-2/

Comment 7

[Florian Quèze [:florian]]

Comment on attachment 8966400 [details]
Bug 1409056. Allow webcompat-reporter addon to ride the trains.

https://reviewboard.mozilla.org/r/235102/#review240928

I don't want to block this so r+, but it's unfortunate that this is going to cause code to be loaded before the browser UI for no use for most users (ie. release users). I wonder if this can be fixed when converting webcompat-reporter away from a bootstrapped extension (ie. bug 1451485).

Comment 8

[Mike Taylor [:miketaylr]]

(In reply to Florian Quèze [:florian] from comment #7) 
> I don't want to block this so r+, but it's unfortunate that this is going to
> cause code to be loaded before the browser UI for no use for most users (ie.
> release users). I wonder if this can be fixed when converting
> webcompat-reporter away from a bootstrapped extension (ie. bug 1451485).

Is there anything we could do in the short-term to mitigate any side-effects of this?

Comment 9

[Florian Quèze [:florian]]

(In reply to Mike Taylor [:miketaylr] from comment #8)
> (In reply to Florian Quèze [:florian] from comment #7) 
> > I don't want to block this so r+, but it's unfortunate that this is going to
> > cause code to be loaded before the browser UI for no use for most users (ie.
> > release users). I wonder if this can be fixed when converting
> > webcompat-reporter away from a bootstrapped extension (ie. bug 1451485).
> 
> Is there anything we could do in the short-term to mitigate any side-effects
> of this?

It's a cost we are paying for each system add-on (they are all loaded at startup when the add-on manager starts), so we could reduce it by reducing the number of system add-ons. In this case we could merge webcompat-reporter into webcompat. I'm not sure why they are 2 different add-ons, if it was just so that a part of the code was shipped to only the nightly population, then shipping it to everybody means it's time to merge the two.

That said, I don't expect the startup performance difference to be significant enough to be visible on Talos or Telemetry (or I wouldn't have r+'ed).

Comment 10

[Mike Taylor [:miketaylr]]

OK, thanks. I think long-term it makes sense to merge the addons.

Comment 11

[Mike Taylor [:miketaylr]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b72ac22c3a6d463786aba43f148adc71ba3e165e just to prove this thing builds.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/32ae04d4e132
Allow webcompat-reporter addon to ride the trains. r=florian

Comment 13

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/32ae04d4e132