Closed Bug 881683 Opened 12 years ago Closed 10 years ago

Disable app install from the browser and apps in settings

Categories

(Firefox OS Graveyard :: Gaia::System, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: pancake, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release) Build ID: 20130514235004 Steps to reproduce: Go browse the web with the web browser and open a page that runs install / installPackage() apis. Actual results: A wild popup appears interrupting the browsing experience and probably tricking the user to install undesired applications. Expected results: Ignore such events if defined in settings or just make a non-intrusive notification (like a color bar on top of the page to install the app if not installed). Also, I guess many webpages will use webapp installs to provide a more reliable way to access the contents of their site, so maybe it would be good to be able to launch the app if it is already installed (requires user interaction). I think that the current settings can be dangerous or confusing to end users (not developers) when using the browser by tricking them to install fake 'twitter apps' or so (for example), using the marketplace as the only install method by default can be safer, and that's what more users will expect.
Group: core-security
The bug request sounds like you want app install prompts to use doorhangers instead of modal prompts to avoid the scenarios you are describing. That would need to get buy-in from UX.
Component: General → Gaia::System
What about adding an option in settings to enable/disable this feature? I think that the user should be notified that the web is trying to install an app and changing settings is required to proceed (just a small doorhang note). IMHO This option should be enabled on developer builds and disabled on release ones.
(In reply to pancake from comment #2) > What about adding an option in settings to enable/disable this feature? That's probably a bad idea. We want users to have the ability to install these apps. > > I think that the user should be notified that the web is trying to install > an app and changing settings is required to proceed (just a small doorhang > note). That would be quite a bad UX. We want users to be able to install apps outright through a pop-up. There's no reason to introduce a settings option to enable this. > > IMHO This option should be enabled on developer builds and disabled on > release ones. I don't agree that design.
A doorhanger seems better for me, like in Firefox Desktop.
Aren't we ignoring calls to .install() if not coming from a user interaction?
(In reply to Mounir Lamouri (:mounir) from comment #5) > Aren't we ignoring calls to .install() if not coming from a user interaction? Nope, those calls are totally legit, and I don't see anything wrong for using them in that way. The problem maybe is just the way it requests the user for that it's too intrusive.
Fabrice, why are we checking that the call is made from a caller in foreground but not from a user interaction?
Flags: needinfo?(fabrice)
(In reply to Mounir Lamouri (:mounir) from comment #7) > Fabrice, why are we checking that the call is made from a caller in > foreground but not from a user interaction? Because that fails with many use cases where the user triggers an async call and we end up doing the "dangerous" call in the the callback. We had this same issue with activities: several apps were calling MozActivity after getting data from a devicestorage or indexedDB callback.
Flags: needinfo?(fabrice)
(In reply to Fabrice Desré [:fabrice] from comment #8) > (In reply to Mounir Lamouri (:mounir) from comment #7) > > Fabrice, why are we checking that the call is made from a caller in > > foreground but not from a user interaction? > > Because that fails with many use cases where the user triggers an async call > and we end up doing the "dangerous" call in the the callback. We had this > same issue with activities: several apps were calling MozActivity after > getting data from a devicestorage or indexedDB callback. Are people trying to call .install() after digging some data from IDB? Why?
I don't know why people are doing strange things sometimes. That also happens to me.
IMO, .install() should be blocked if not initiated by a user event unless we have a strong reason to not do that and I haven't heard one yet.
Can you please update the status of this bug, I am leaving this open for one week after which i am going to mark this as wont fix due to the age of this bug.
Flags: needinfo?(mounir)
Flags: needinfo?(fabrice)
adding this so I can come back to it later to update if not already done
Flags: needinfo?(charja13)
We have a new app install model coming up, so I don't think we'll fix this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(mounir)
Flags: needinfo?(fabrice)
Resolution: --- → FIXED
Resolution: FIXED → WONTFIX
clearing the NI
Flags: needinfo?(charja13)
You need to log in before you can comment on or make changes to this bug.