Closed
Bug 776668
Opened 12 years ago
Closed 12 years ago
Split permission for Settings/Contacts access into ReadOnly and ReadWrite variants
Categories
(Core :: DOM: Device Interfaces, defect, P2)
Core
DOM: Device Interfaces
Tracking
()
People
(Reporter: cjones, Assigned: gwagner)
References
Details
(Whiteboard: [LOE:S])
Attachments
(1 file)
(deleted),
patch
|
ddahl
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Updated•12 years ago
|
blocking-basecamp: --- → +
Comment 1•12 years ago
|
||
Chris - Can you give more context on what this bug is and help us find an assignee?
Reporter | ||
Updated•12 years ago
|
Assignee: nobody → anygregor
Updated•12 years ago
|
Whiteboard: [WebAPI:P2]
Assignee | ||
Updated•12 years ago
|
Whiteboard: [WebAPI:P2] → [WebAPI:P2][LOE:S]
Comment 2•12 years ago
|
||
This may seem artificial to remove it at this point but Gregor told me that he and Jonas decided this and bug 776671 aren't features so I'm removing the feature keyword.
Keywords: feature
Updated•12 years ago
|
Priority: -- → P2
Whiteboard: [WebAPI:P2][LOE:S] → [LOE:S]
Can we morph this to cover read vs. write privileges for the settings API?
Assignee | ||
Comment 4•12 years ago
|
||
(In reply to ben turner [:bent] from comment #3) > Can we morph this to cover read vs. write privileges for the settings API? Yes we can!
Updated•12 years ago
|
Summary: Check capabilities for Settings access → Split permission for Settings access into ReadOnly and ReadWrite variants
Assignee | ||
Comment 5•12 years ago
|
||
For settings and contacts
Assignee | ||
Updated•12 years ago
|
Summary: Split permission for Settings access into ReadOnly and ReadWrite variants → Split permission for Settings/Contacts access into ReadOnly and ReadWrite variants
Assignee | ||
Updated•12 years ago
|
Attachment #675411 -
Flags: review?(ddahl)
Comment 7•12 years ago
|
||
Comment on attachment 675411 [details] [diff] [review] patch Review of attachment 675411 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, only a few nits. ::: dom/contacts/ContactManager.js @@ +446,5 @@ > + break > + case "update": > + case "remove": > + access = "write"; > + break nit: break; ::: dom/contacts/fallback/ContactService.jsm @@ +68,5 @@ > }, > > + assertPermission: function(aMessage, aPerm) { > + if (!aMessage.target.assertPermission(aPerm)) { > + dump("Contacts message " + msg.name + debug() instead of dump()? ::: dom/settings/SettingsChangeNotifier.jsm @@ +80,5 @@ > let mm = aMessage.target; > switch (aMessage.name) { > case "Settings:Changed": > + if (!aMessage.target.assertPermission("settings-write")) { > + dump("Settings message " + msg.name + debug() instead of dump() - or should this be Cu.reportError()? - same with above? ::: dom/settings/SettingsManager.js @@ +339,5 @@ > + this.hasReadPrivileges = readPerm == Ci.nsIPermissionManager.ALLOW_ACTION; > + this.hasWritePrivileges = writePerm == Ci.nsIPermissionManager.ALLOW_ACTION; > + > + if (!this.hasReadPrivileges && !this.hasWritePrivileges) { > + dump("NO SETTINGS PERMISSION FOR: " + aWindow.document.nodePrincipal.origin + "\n"); I think if we want these messages to bubble up when developers are wokring on apps, etc, we want to use Cu.reportError instead of dump
Attachment #675411 -
Flags: review?(ddahl) → review+
Assignee | ||
Comment 8•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/858e49a77dca
Comment 9•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/858e49a77dca
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Assignee | ||
Comment 10•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/501dd2c7deea
status-firefox18:
--- → fixed
status-firefox19:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•