1283799 - No software button

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[:gerard-majax]

> [JavaScript Error: "TypeError: this._currentOrientation.contains is not a function" {file: "chrome://gaia/content/system/js/software_button_manager.js" line: 320}]

Comment 1

[:gerard-majax]

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 :)

Comment 2

[Jovan Gerodetti]

okay I will fix it :)

Comment 3

[:gerard-majax]

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?

Comment 4

[Jovan Gerodetti]

yes, I think so too. shouldn't be hard to fix that.

Comment 5

[:gerard-majax]

Attachment: hack

Hacked this but it's not enough, and I dont have more time for now.

Comment 6

[Jovan Gerodetti]

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?

Comment 7

[:gerard-majax]

I have absolutely no idea :) You probably have to dig in the MDN docs and code maybe?

Comment 8

[Jovan Gerodetti]

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?

Comment 9

[:gerard-majax]

Using gdb? Check run-gdb.sh in B2G/ ?

Comment 10

[Jovan Gerodetti]

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?

Comment 11

[:gerard-majax]

I have no idea !

Comment 12

[William Chen [:wchen]]

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).

Comment 13

[William Chen [:wchen]]

Attachment: test fix

Comment 14

[[:fabrice] Fabrice Desré]

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.

Comment 15

[[:fabrice] Fabrice Desré]

Attachment: lock-orientation.patch

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.

Comment 16

[[:fabrice] Fabrice Desré]

This was broken by the removal of the -moz-full-screen-ancestor css selector. See bug 1235472

Comment 17

[:gerard-majax]

I guess we can close this now that bug 1235472 landed.