Add finalized actions or urls for Monitor report's "Sign up" / "Turn on" monitor buttons
Categories
(Firefox :: Protections UI, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: mtigley, Assigned: mtigley)
References
Details
(Whiteboard: [skyline])
Attachments
(1 file)
The Monitor report's "Sign up" and "Turn on" Monitor buttons need to perform some sort of action when they are pressed. In each case:
- The "Sign up for Monitor" button should take a user who is not logged in someplace where they can sign up for Monitor.
- The "Turn on Monitor" button should take a user who is logged in but not subscribed to Monitor someplace where they can do this.
In both cases, the user needs some kind of workflow where they can perform either action, whether this is being taken to another page or hitting single or multiple endpoints.
The context for this work is being outlined in Bug 1567405.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
The "Sign up for Monitor" button should take a user who is not logged in someplace where they can sign up for Monitor.
IIUC this is for users who are not signed in to Sync in their browser.
As noted here we need to be clear on what the call-to-action will be for these users. Do we want to ask them to sign in to Sync, so that the browser gets all the auth tokens it needs to display Monitor data in the protection report? Or, do we want to direct them out to Monitor on the web, which will mean that protection-report stays in the "Sign up for Monitor" state unless and until the user signs in to Sync for some other reason?
I believe we intend to direct them out to Monitor on the web, but am not sure if Betsy has any further thoughts based on conversations from last week. Betsy?
I think we should start by having both "Sign up for Monitor" and "Turn on Monitor" open the monitor.firefox.com signin flow in a new tab, as described in Bug 1567405 Comment 1. It's the simplest thing that could possibly work, and would give a good concrete starting point for discussing improvements.
Comment 2•6 years ago
|
||
Do we want to ask them to sign in to Sync, so that the browser gets all the auth tokens it needs to display Monitor data in the protection report
On the other hand, if we do in fact want to sign them in to Sync, there's an example of how do achieve that here.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 3•6 years ago
|
||
Comment 4•6 years ago
|
||
I believe we intend to direct them out to Monitor on the web, but am not sure if Betsy has any further thoughts based
on conversations from last week. Betsy?
We met to discuss, and confirmed that we should indeed do the "direct them out to Monitor on the web" thing, as implemented in the attached patch. So it sounds like everything in this bug is on the right track UX-wise.
Comment 6•6 years ago
|
||
Backed out changeset ad5382b6b11e for causing failures in protections.css
Backout link: https://hg.mozilla.org/integration/autoland/rev/a177da40f0e09fd35d170d42bef7fdf9238b4447
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=258429747&repo=autoland&lineNumber=3576
[task 2019-07-26T01:58:56.983Z] 01:58:56 INFO - Ignored error "Unknown pseudo-class or pseudo-element ‘-moz-svg-marker-anon-child’. Ruleset ignored due to bad selector." on resource://gre/res/svg.css because of whitelist item {"sourceName":"/\b(contenteditable|EditorOverride|svg|forms|html|mathml|ua|pluginproblem)\.css$/i","errorMessage":"/Unknown pseudo-class.*-moz-/i","isFromDevTools":false,"used":true}
[task 2019-07-26T01:58:56.983Z] 01:58:56 INFO - Buffered messages finished
[task 2019-07-26T01:58:56.983Z] 01:58:56 INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/static/browser_parsable_css.js | Got error message for chrome://browser/content/protections.css: Unknown pseudo-class or pseudo-element ‘focus-visible’. Ruleset ignored due to bad selector. -
[task 2019-07-26T01:58:56.983Z] 01:58:56 INFO - Stack trace:
[task 2019-07-26T01:58:56.983Z] 01:58:56 INFO - chrome://mochikit/content/browser-test.js:test_ok:1576
[task 2019-07-26T01:58:56.983Z] 01:58:56 INFO - chrome://mochitests/content/browser/browser/base/content/test/static/browser_parsable_css.js:messageIsCSSError:294
[task 2019-07-26T01:58:56.983Z] 01:58:56 INFO - chrome://mochitests/content/browser/browser/base/content/test/static/browser_parsable_css.js:checkAllTheCSS:515
[task 2019-07-26T01:58:56.983Z] 01:58:56 INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1346
[task 2019-07-26T01:58:56.983Z] 01:58:56 INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1381
[task 2019-07-26T01:58:56.984Z] 01:58:56 INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1209
[task 2019-07-26T01:58:56.984Z] 01:58:56 INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:803
[task 2019-07-26T01:58:56.984Z] 01:58:56 INFO - Not taking screenshot here: see the one that was previously logged
[task 2019-07-26T01:58:56.984Z] 01:58:56 INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/static/browser_parsable_css.js | All the styles (227) loaded without errors. - Got 1, expected 0
[task 2019-07-26T01:58:56.984Z] 01:58:56 INFO - Stack trace:
[task 2019-07-26T01:58:56.984Z] 01:58:56 INFO - chrome://mochikit/content/browser-test.js:test_is:1591
[task 2019-07-26T01:58:56.984Z] 01:58:56 INFO - chrome://mochitests/content/browser/browser/base/content/test/static/browser_parsable_css.js:checkAllTheCSS:516
Assignee | ||
Comment 8•6 years ago
|
||
The failed test was a result of using an experimental pseudo-class, focus-visible
, for the Monitor link.
Comment 9•6 years ago
|
||
bugherder |
Description
•