Closed Bug 1183553 Opened 9 years ago Closed 9 years ago

[Control Center] Update copy for TP section

Categories

(Firefox :: General, defect, P1)

defect
Points:
1

Tracking

()

VERIFIED FIXED
Firefox 42
Iteration:
42.2 - Jul 27
Tracking Status
firefox42 --- verified

People

(Reporter: ttaubert, Assigned: ttaubert)

References

(Depends on 1 open bug, )

Details

(Whiteboard: [fxprivacy] [campaign])

Attachments

(1 file, 1 obsolete file)

Copy is finished, let's update labels and buttons.
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Iteration: --- → 42.1 - Jul 13
Points: --- → 1
Whiteboard: [fxprivacy]
Flags: qe-verify+
Flags: firefox-backlog+
Iteration: 42.1 - Jul 13 → 42.2 - Jul 27
Rank: 1
Priority: -- → P1
QA Contact: mwobensmith
Comment on attachment 8633377 [details] [diff] [review]
0001-Bug-1183553-Control-Center-Update-copy-for-TP-sectio.patch

Review of attachment 8633377 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/locales/en-US/chrome/browser/browser.dtd
@@ +772,5 @@
>  <!ENTITY trackingProtection.title "Tracking Protection">
> +<!ENTITY trackingProtection.detectedBlocked2 "&brandShortName; is blocking attempts to track your browsing.">
> +<!ENTITY trackingProtection.detectedNotBlocked2 "This site includes content that tracks your browsing. You have disabled protection.">
> +<!ENTITY trackingProtection.notDetected2 "This site doesn’t include any content that tracks your browsing.">
> +<!ENTITY trackingProtection.unblock2.label "Disable protection for this session">

This string isn't accurate for non-private browsing, since the exceptions *will* persist across sessions.

I assume we are optimizing for PB mode right now, but do we want to have another string to distinguish between the two modes on that button?  Fine to be a follow up, but worth checking
Attachment #8633377 - Flags: review?(bgrinstead) → review+
(In reply to Brian Grinstead [:bgrins] from comment #2)
> This string isn't accurate for non-private browsing, since the exceptions
> *will* persist across sessions.
> 
> I assume we are optimizing for PB mode right now, but do we want to have
> another string to distinguish between the two modes on that button?  Fine to
> be a follow up, but worth checking

Ha, that's a good point. I think doing this right shouldn't be too hard. I'll upload another patch.
Comment on attachment 8634687 [details] [diff] [review]
0001-Bug-1183553-Control-Center-Update-copy-for-TP-sectio.patch, v2

Review of attachment 8634687 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/locales/en-US/chrome/browser/browser.dtd
@@ +776,4 @@
>  <!ENTITY trackingProtection.unblock.label "Disable protection for this site">
>  <!ENTITY trackingProtection.unblock.accesskey "D">
> +<!ENTITY trackingProtection.unblockPrivate.label "Disable protection for this session">
> +<!ENTITY trackingProtection.unblockPrivate.accesskey "D">

Does this really need it's own accesskey?  I can't imagine a situation where we would want a different value for the button btw private mode and non-private, so maybe the private button can just reuse trackingProtection.unblock.accesskey?
Attachment #8634687 - Flags: review?(bgrinstead) → review+
(In reply to Brian Grinstead [:bgrins] from comment #5)
> >  <!ENTITY trackingProtection.unblock.label "Disable protection for this site">
> >  <!ENTITY trackingProtection.unblock.accesskey "D">
> > +<!ENTITY trackingProtection.unblockPrivate.label "Disable protection for this session">
> > +<!ENTITY trackingProtection.unblockPrivate.accesskey "D">
> 
> Does this really need it's own accesskey?  I can't imagine a situation where
> we would want a different value for the button btw private mode and
> non-private, so maybe the private button can just reuse
> trackingProtection.unblock.accesskey?

I thought about a weird language where both of these might end up with different accesskeys but maybe that's overly cautious. I'll remove the second.
https://hg.mozilla.org/mozilla-central/rev/689cd81e0f3c
https://hg.mozilla.org/mozilla-central/rev/57678f59be20
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42
(In reply to Tim Taubert [:ttaubert] from comment #6)
> I thought about a weird language where both of these might end up with
> different accesskeys but maybe that's overly cautious. I'll remove the
> second.

Your first patch was the right approach: do not reuse accesskeys for different labels.

a) It's confusing
b) It doesn't work for tools trying to match label and accesskeys in one view
c) It's not 100% safe

Not sure if you prefer me to file a follow-up bug or reuse this one.
Flags: needinfo?(ttaubert)
(In reply to Francesco Lodolo [:flod] from comment #10)
> (In reply to Tim Taubert [:ttaubert] from comment #6)
> > I thought about a weird language where both of these might end up with
> > different accesskeys but maybe that's overly cautious. I'll remove the
> > second.
> 
> Your first patch was the right approach: do not reuse accesskeys for
> different labels.
> 
> a) It's confusing
> b) It doesn't work for tools trying to match label and accesskeys in one view
> c) It's not 100% safe
> 
> Not sure if you prefer me to file a follow-up bug or reuse this one.

Sorry, my mistake.  Seems alright to just land a follow up patch here with the separate accesskey
Will push a follow-up in a second.
Flags: needinfo?(ttaubert)
Whiteboard: [fxprivacy] → [fxprivacy] [campaign]
Verified in Nightly Fx42.0a1, 2015-07-27.
Status: RESOLVED → VERIFIED
Depends on: 1225819
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: