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)
Firefox OS Graveyard
Gaia::System
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.
Updated•12 years ago
|
Group: core-security
Comment 1•12 years ago
|
||
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.
Comment 3•12 years ago
|
||
(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.
Comment 4•12 years ago
|
||
A doorhanger seems better for me, like in Firefox Desktop.
Comment 5•12 years ago
|
||
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.
Comment 7•12 years ago
|
||
Fabrice, why are we checking that the call is made from a caller in foreground but not from a user interaction?
Flags: needinfo?(fabrice)
Comment 8•12 years ago
|
||
(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)
Comment 9•12 years ago
|
||
(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?
Comment 10•12 years ago
|
||
I don't know why people are doing strange things sometimes. That also happens to me.
Comment 11•12 years ago
|
||
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.
Comment 12•10 years ago
|
||
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)
Comment 13•10 years ago
|
||
adding this so I can come back to it later to update if not already done
Flags: needinfo?(charja13)
Comment 14•10 years ago
|
||
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
Updated•10 years ago
|
Resolution: FIXED → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•