Closed
Bug 740922
Opened 13 years ago
Closed 12 years ago
mozApps.launch() should not launch a pinned tab in Firefox - behavior should be like the HTML 5 shim
Categories
(Firefox Graveyard :: Web Apps, defect, P1)
Tracking
(blocking-kilimanjaro:+)
RESOLVED
INVALID
blocking-kilimanjaro | + |
People
(Reporter: Mardak, Unassigned)
References
(Blocks 1 open bug)
Details
Launching apps from Firefox should have a consistent experience as launching from desktop/outside of Firefox. Launching it as a pinned tab could lead to a mixed experience where cookies, local storage, profile/prefs might result in different app behavior.
Reporter | ||
Comment 1•13 years ago
|
||
Just want to confirm that because bug 725408 is targeting only Windows and Mac for now, Linux will have no native runtime, so the behavior of mozApps.launch() is undefined. UX team (Limi/Boriss) has provided feedback confirming that we want the consistent launch experience from inside Firefox and outside Firefox.
So should the behavior on Linux be to just inform the user that the app cannot be launched? I suppose a dashboard should also be proactive in not giving the user the impression an app can be launched.
OS: Mac OS X → All
Hardware: x86 → All
Comment 2•13 years ago
|
||
I don't think launching as a pinned tab is supported for the web apps integration into desktop feature, even though it was supported in the extension. I'll double check this though. Myk - Could you clarify?
Also - Adding the mozApps API guys to provide insight into here to determine the root cause of this issue.
Comment 3•13 years ago
|
||
(In reply to Jason Smith from comment #2)
> I don't think launching as a pinned tab is supported for the web apps
> integration into desktop feature, even though it was supported in the
> extension. I'll double check this though. Myk - Could you clarify?
Hmm, it's true that we're not working on support for launching apps as pinned tabs.
However, I was also under the impression that we weren't going to support launching from Firefox at all; which is obviously a different message than the one Ed got from UX.
Reporter | ||
Comment 4•13 years ago
|
||
(In reply to Myk Melez [:myk] [@mykmelez] from comment #3)
> However, I was also under the impression that we weren't going to support
> launching from Firefox at all; which is obviously a different message than
> the one Ed got from UX.
To be clear, "launching from Firefox" came from Ragavan wanting an additional screen-space for users to see their (persona) apps and find new (marketplace) apps. UX was somewhat hesitant but is willing to experiment and see if users adopt this method of launching apps.
UX just wanted to make sure that launching apps from Firefox was consistent with launching outside -- i.e., separate window and no pinned tab.
I filed this bug because what has landed is mozApps.launch() triggering the pinned tab behavior, which is exactly the opposite of what UX suggests.
Reporter | ||
Comment 5•13 years ago
|
||
Current behavior in mozilla-central:
https://hg.mozilla.org/mozilla-central/rev/374977a5f8c6#l7.39
case "webapps-launch":
this.openURL(manifest.fullLaunchPath(), data.origin);
https://hg.mozilla.org/mozilla-central/rev/374977a5f8c6#l7.50
if (!found) {
let tab = browser.addTab(aUrl);
browser.pinTab(tab);
Comment 6•13 years ago
|
||
I've confirmed what Ed is talking about. If enable the HTML 5 dashboard by whitelisting it in a hidden pref, launching apps from the dashboard does indeed launch the app in a pinned tab. I think what Ed is implying here that the experience should be the same as the Web Apps experience as native desktop, which does make sense from a UX perspective.
Let's get Fabrice's opinion on this, as he was the one who made the check-in into mozilla central. Fabrice - Could you provide your insight on this?
Comment 7•13 years ago
|
||
When I wrote desktop support it made no sense to have no way to launch apps. Hence I choose to implement this as pinned tabs, and adding the origin into the session store so they are reused and restored appropriately.
I understand that on platforms that have "native" support we should launch the native version instead. Whoever will add support for that, remember that removing a native app doesn't remove it from the webapps repository, so it will still show on the dashboard and still needs to be launchable.
Also, I think we should have a pref to let the user choose it's preferred way of launching apps.
Comment 8•13 years ago
|
||
Ragavan & Jen - Could you also provide insight into what's the expected behavior here? There appears to be some confusion.
Updated•13 years ago
|
Whiteboard: [marketplace-beta?]
Reporter | ||
Comment 9•13 years ago
|
||
felipe was suggesting that webapps.json should store the installDir of each native app. Launching on each platform might be as simple as checking the installDir and executing it.
Might be out of the scope of this bug, but maybe there should be a flag on mozApps App objects to indicate if the installDir exists (and launchable)? Or would mozApps.getSelf and mozApps.mgmt.getAll not return Apps that don't exist locally?
Comment 10•13 years ago
|
||
Ragavan - Could I get a decision on this bug? I don't recall this being the requirements to do pinned tabs anymore on mozApps.launch. If that's the case, let's at least revert the functionality to match the HTML 5 shim functionality (a new tab opens, not a new app tab).
Updated•13 years ago
|
Comment 11•13 years ago
|
||
For scoping purposes, I'm going to reword this bug to only talk about the pinned tabs issue. I'll open a separate bug for allowing native launch apps from the dashboard (that's a feature request, the pin tab issue is a bug).
Updated•13 years ago
|
Summary: mozApps.launch() should launch with the runtime instead of as a pinned tab in Firefox → mozApps.launch() should not launch a pinned tab in Firefox - behavior should be like the HTML 5 shim
Comment 12•13 years ago
|
||
Opening apps in pin tabs is a better user experience IMHO. Just because it can not be done with the html shim (that should not be used in firefox anyway) is a poor reason to not use pinned tabs.
Comment 13•13 years ago
|
||
Given that in the Fx14 time frame were are targeting app support for Firefox users this is the behavior and hence the requirements so that we maintain the mental model that users have of apps that they run outside the browser.
The requirement for April 26th, Fx14 merge for th HTML5 dashboard was to:
1. View all your installed apps
2. Install an app natively from the dashboard
3. Re-install an "installed" app natively
So deciding whether an app gets launched as a pinned tab or a tab is a moot point right now since the HTML5 dashboard in Firefox desktop will not be launching apps for Fx14 user experience.
Comment 14•13 years ago
|
||
(In reply to Jennifer Arguello :ticachica from comment #13)
> So deciding whether an app gets launched as a pinned tab or a tab is a moot
> point right now since the HTML5 dashboard in Firefox desktop will not be
> launching apps for Fx14 user experience.
And what will be the behavior on platforms where we don't support native install?
Comment 15•13 years ago
|
||
We have not given this a lot of design time yet so there is not hard requirement for Fx14 since it's not a case we're giving much attention to.
Do other browsers have the concept of pinned tab vs. real tab? Can't we just keep it to launch in a tab?
This is not a blocker and so until we flesh out the user experience better on other browsers lets keep it simple.
Reporter | ||
Comment 16•13 years ago
|
||
(In reply to Jennifer Arguello :ticachica from comment #13)
> The requirement for April 26th, Fx14 merge for th HTML5 dashboard was to:
> 1. View all your installed apps
Where are people viewing their installed apps? http://persona.org ? Or even from Marketplace, if the site uses the mozApps API to launch an app, it will open up a pinned tab.
https://myapps.mozillalabs.com right now shows me my apps in the regular Nightly, and clicking it launches a pinned tab.
Comment 17•13 years ago
|
||
FYI - This behavior is currently active on FF 13 & 14 (Aurora and Nightly). Comes back to the fact that we need to get this out of Aurora per bug 741415, given that there's still churn on what needs to be implemented (not stable enough for Aurora).
Comment 18•13 years ago
|
||
@Ed I am not sure which site will be used for the dashboard so that's what is causing confusion. Let me talk to folks and get that settled.
the goal of Fx14 is to get the basics of AitC working. it may be that we just use the Marketplace "My Purchases" as the dashboard for users in Fx14.
And we can iterate on the persona.org in the Fx15 nightly time frame.
@Jason
I am sensitive to there being left over functionality from Fx13. I need to better understand where this behavior so that we can identify what needs to be done.
Updated•13 years ago
|
Whiteboard: [marketplace-beta?]
Updated•13 years ago
|
Whiteboard: [marketplace-beta-]
Comment 19•13 years ago
|
||
marking this a blocker for now. we need to figure out this use case and either decide to turn it off or to support it properly.
blocking-kilimanjaro: --- → +
Updated•12 years ago
|
Version: unspecified → 15 Branch
Updated•12 years ago
|
Whiteboard: [marketplace-beta-]
Updated•12 years ago
|
Priority: -- → P1
Updated•12 years ago
|
Target Milestone: Future → ---
Comment 21•12 years ago
|
||
Given that we are going directly now to implementing launching the runtime directly instead of doing the HTML 5 shim, I don't think we need this bug anymore. Let's track work for this in the bug that will have work for this - bug 745924. Resolving as invalid, as we will not be doing this anymore.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Comment 22•12 years ago
|
||
Well, we'll need at least to remove that code cleanly if it is unused.
Comment 23•12 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #22)
> Well, we'll need at least to remove that code cleanly if it is unused.
Right. We should include the backout of that as part of the patch for bug 745924.
Assignee | ||
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•