Closed
Bug 1183553
Opened 9 years ago
Closed 9 years ago
[Control Center] Update copy for TP section
Categories
(Firefox :: General, defect, P1)
Firefox
General
Tracking
()
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)
6.67 KB,
patch
|
bgrins
:
review+
|
Details | Diff | Splinter Review |
Copy is finished, let's update labels and buttons.
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Iteration: --- → 42.1 - Jul 13
Points: --- → 1
Whiteboard: [fxprivacy]
Assignee | ||
Updated•9 years ago
|
Flags: qe-verify+
Flags: firefox-backlog+
Assignee | ||
Comment 1•9 years ago
|
||
Attachment #8633377 -
Flags: review?(bgrinstead)
Updated•9 years ago
|
Iteration: 42.1 - Jul 13 → 42.2 - Jul 27
Rank: 1
Priority: -- → P1
QA Contact: mwobensmith
Comment 2•9 years ago
|
||
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+
Assignee | ||
Comment 3•9 years ago
|
||
(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.
Assignee | ||
Comment 4•9 years ago
|
||
Attachment #8633377 -
Attachment is obsolete: true
Attachment #8634687 -
Flags: review?(bgrinstead)
Comment 5•9 years ago
|
||
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+
Assignee | ||
Comment 6•9 years ago
|
||
(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.
Comment 9•9 years ago
|
||
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
Comment 10•9 years ago
|
||
(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)
Comment 11•9 years ago
|
||
(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
Updated•9 years ago
|
Whiteboard: [fxprivacy] → [fxprivacy] [campaign]
You need to log in
before you can comment on or make changes to this bug.
Description
•