Closed Bug 781076 Opened 9 years ago Closed 9 years ago

System app cannot access Idle API (Because it is not considered certified?)

Categories

(Firefox OS Graveyard :: General, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:+)

RESOLVED FIXED
blocking-basecamp +

People

(Reporter: timdream, Assigned: fabrice)

References

Details

(Whiteboard: [fixed by bug 781620])

Idle API have stop working and failed a few days ago. The interface is still there but calling it (wrapping it in |try .. catch (e) { console.log (e)}|) gives the following error:

E/GeckoConsole(  881): Content JS LOG at app://system.gaiamobile.org/js/screen_manager.js:290 in scm_setIdleTimeout: [Exception... "The operation is insecure."  code: "18" nsresult: "0x80530012 (SecurityError)"  location: "app://system.gaiamobile.org/js/screen_manager.js Line: 288"]

For a certified app, this error should not be generated and Idle API should work. For a non-certified app, interface should not be there (should be |null|).
Related bug and comment is bug 780507 comment 7
blocking-basecamp: --- → ?
Doesn't look like Gecko even uses APP_STATUS_CERTIFIED anywhere.
Gregor, do you happen to know if the idle API got permission-ified?  Perhaps the system app doesn't have this permission?
We need to fix bug 768868 for that
(In reply to Chris Jones [:cjones] [:warhammer] from comment #3)
> Gregor, do you happen to know if the idle API got permission-ified?  Perhaps
> the system app doesn't have this permission?

It got certified-only-ified, per the security discussion.  Maybe that was the wrong thing to do?
I don't know of any use cases for extremely high-precision idle timing outside the system.  I think I meant what fabrice said.
(In reply to Justin Lebar [:jlebar] from comment #2)
> Doesn't look like Gecko even uses APP_STATUS_CERTIFIED anywhere.

Actually, that's something we should fix: we have no way currently to mark an app as TRUSTED or CERTIFIED. I should have think about that before r+'ing the patch :(.
(In reply to Mounir Lamouri (:mounir) from comment #7)
> (In reply to Justin Lebar [:jlebar] from comment #2)
> > Doesn't look like Gecko even uses APP_STATUS_CERTIFIED anywhere.
> 
> Actually, that's something we should fix: we have no way currently to mark
> an app as TRUSTED or CERTIFIED. I should have think about that before r+'ing
> the patch :(.

Do we have a bug number for that?
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #8)

> 
> Do we have a bug number for that?

See comment #4 : bug 768868
(In reply to Fabrice Desré [:fabrice] from comment #9)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #8)
> 
> > 
> > Do we have a bug number for that?
> 
> See comment #4 : bug 768868

Oh, sorry about that. So this bug is a dup of that right?
It's more a consequence than really a dupe. But for sure this bug will be moot once 768868 is done.
Depends on: 768868
Depends on: 781620
No longer depends on: 768868
blocking-basecamp: ? → +
We think this will be fixed when the dependent bug is fixed.  Just needs to be verified.
Keywords: qawanted
QA Contact: gmealer
This is on the list of things to test re: permissions. We may be able to get to it quicker w/ our on-device exercise. I'll update as soon as we have verification.
Given that this bug is going to be fixed by bug 781620. I'm assigning to Fabrice so it will leave un-assigned blocking bug list.
Assignee: nobody → fabrice
OS: Mac OS X → All
Hardware: x86 → All
Geo, can you verify this?
Fabrice, as mentioned in comment 13, we'll be able to verify via testing that -a- certified app can access Idle API.

If the problem is specifically that the System app can't do it, that's a little bit trickier. Easiest then would be for Tim to verify that the app works again per however he generated the above error.
(In reply to Geo Mealer [:geo] from comment #16)
> Fabrice, as mentioned in comment 13, we'll be able to verify via testing
> that -a- certified app can access Idle API.
> 
> If the problem is specifically that the System app can't do it, that's a
> little bit trickier. Easiest then would be for Tim to verify that the app
> works again per however he generated the above error.

Boot up the phone and |adb logcat | grep screen| then you will see the error.
Calling |addIdleObserver| no longer generates security error on Otoro. I am trying to see if actually works right now.
Yeah it works.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → FIXED
Whiteboard: [fixed by bug 781620]
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.