Closed Bug 1283799 Opened 4 years ago Closed 4 years ago

No software button

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gerard-majax, Unassigned)

References

Details

Attachments

(3 files)

> [JavaScript Error: "TypeError: this._currentOrientation.contains is not a function" {file: "chrome://gaia/content/system/js/software_button_manager.js" line: 320}]
Jovan, do you want to help on this? It's the only big visible problem for the current m-c => pine merge. If there are no other build/boot issue except this, I'll merge anyway so we get broken software home button :)
Flags: needinfo?(titannanomail)
okay I will fix it :)
Jovan, I'm pushing the merge right now. Checking the WebIDL, it looks like mozOrientation is DEPRECATED, and it is recommended to switch to ScreenOrientation API. We should fix this on Gaia I guess?
yes, I think so too. shouldn't be hard to fix that.
Attached file hack
Hacked this but it's not enough, and I dont have more time for now.
calling window.screen.orientation.lock() gives me this error:

E/GeckoConsole(26084): [JavaScript Error: "SecurityError: The operation is insecure." {file: "chrome://gaia/content/system/js/app_window.js" line: 1809}]

what needs to be done to get this working? How could help?
Flags: needinfo?(titannanomail) → needinfo?(lissyx+mozillians)
I have absolutely no idea :) You probably have to dig in the MDN docs and code maybe?
Flags: needinfo?(lissyx+mozillians)
How can I debug C++ on B2G? Unfortunately William Chen doesn't respond to me anymore, but he told me that C++ debugging is needed in order to find the issue in gecko before. 
I have never done this, any docs how I get started on this? What do I need to know?
Flags: needinfo?(lissyx+mozillians)
Using gdb? Check run-gdb.sh in B2G/ ?
Flags: needinfo?(lissyx+mozillians)
I have good news. I found the problem. Screen orientation locking is only allowed in fullscreen mode.
I guess we want to keep it that way. There is a pref user_pref("dom.screenorientation.testing.non_fullscreen_lock_allow", true); which allows to enable orientation locking outside of fullscreen, but I think that would also allow web content to lock the orientation outside of fullscreen. Can we give orientation locking permissions to the chrome:// context without giving it to web content?
Flags: needinfo?(wchen)
Flags: needinfo?(lissyx+mozillians)
I have no idea !
Flags: needinfo?(lissyx+mozillians)
We already grant permission to chrome [1], this makes me suspect that the page running the script might not be chrome. The permission check for mozLockOrientation calls into the same code as orientation.lock with the main difference being that orientation.lock will also check document sandbox flags. If mozLockOrientation passes permission checks but orientation.lock does not, then I suspect it's due to the script being loaded in a sandboxed document.

Can you try a build of Gecko with the attached patch? It moves the check for installed app status (which is given orientation permission) before the check for sandbox flags (which denies permission if the orienation is not allowed in the sandbox).
Flags: needinfo?(wchen)
Attached patch test fixSplinter Review
That patch doesn't work because even if the documents have chrome:// uris, the docShell type is `content`. And since theses are not apps anymore, the principal status check also fails.
This whitelists chrome://gaia/xxx uris. That gets rid of the orientation errors for me, but we still don't display the software home button.
This was broken by the removal of the -moz-full-screen-ancestor css selector. See bug 1235472
Depends on: 1235472
I guess we can close this now that bug 1235472 landed.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.