In bug 958425 I hacked camera app and make it determine isSecureMode based on the URL hash. We should change that and determine that with |lockscreen.locked| in mozSettings instead. Tentatively mark this as blocking bug of bug 951978 -- the proper/generic fix to bug 958425. Diego, Alive, Greg, do you agree with above fix? Is there any alternative on the table?
I dislike use settings to know it's launched as secure or not. This is not strict. Think about about you're locked but somebody calls launch or activity at background....? I prefer to keep the "hack" until we have better solution.
It seems like that we have such requirement here: 1. Launch an app with some "parameters" 2. The "parameters" depends on who launch the app If it's a generic problem about how to passing something between A app to B app, which A launch B, I would say IAC or Web API. But this is not a classical information exchanging case: it's about launching, and I don't know if IAC can or should handle this case. Does we now have any method except the hash trick can solve this general requirement? If not, we may need to invent new or modify existing ways.
We should have a formal discussion and priority this bug after SecureWindow implementation. If we accept that hash tag is a permanent way to satisfy the requirement, we may over reply on it and invent some extreme strange way to abuse it when we encounter the similar needs (ex: put some hashed JSON or Base64 after the '#' symbol to pass some real complex data? a 'shortcut' to avoid use IAC because of to write manifest is annoying?)
Maybe <iframe mozbrowser name="main-secure"> from the time being?
We still use #secure in camera. Is there already a good alternative in place?
(In reply to Diego Marcos [:dmarcos] from comment #5) > We still use #secure in camera. Is there already a good alternative in place? In comment 0, I was asking whether or not use mozSettings again make sense, and comment 1 and comment 2 suggests that's not a good idea. In comment 4 I propose using |window.name| (while set it with <iframe name=> from embedder). Not sure this is a viable solution either. As the developer of the consumer of this information, I & other system developers can't really force you to do anything you don't want. If you have any good idea please share. I also believe Greg have tried to bring this conversation to dev-webapi without any sound conclusions.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.