User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100808 Minefield/4.0b4pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100808 Minefield/4.0b4pre AppTabs are web-based applications, therefore they don't need chrome. The only question is if they will be chromeless by default or not. Reproducible: Always

Per https://wiki.mozilla.org/Firefox/Projects/Home_Tab/Design "App tabs *may* display less chrome, or have options to do so (none, minimal or all). The default *may* come from the web-app."

This will have to take customization into account. Example: if the location or search widget has been moved to the tab or menu toolbar, should that widget be disabled, removed or left alone?

There are use cases to work out, especially since we are moving a bunch of authentication UI to panel notifications. We'll work through these, of course.

>There are use cases to work out, especially since we are moving a bunch of >authentication UI to panel notifications. We'll work through these, of course. Yeah, those will need to attach to the icon of the site (and be accessible from the panel you get when you hit the site favicon).

I don't believe we should make app tabs chromeless by default. I made my argument here: http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/0dd173f268a16f34 Sorry for being a pain :P

It's unclear from the project page if we've worked through the design for this, especially with respect to: - where security context information goes - how someone gets their toolbars back if they want it - where notifications come from - who will bake the bread Minusing, the UX team can renominate if they feel like it must block a release, but I think we can live without it for Firefox 4.

(In reply to comment #6) > - where security context information goes Doorhanger. > - how someone gets their toolbars back if they want it Option/temporary with hotkey. > - where notifications come from Doorhanger. > Minusing, the UX team can renominate if they feel like it must block a release, > but I think we can live without it for Firefox 4. Speeking for myself: I couldn't.

(In reply to comment #6) > Minusing, the UX team can renominate if they feel like it must block a release, > but I think we can live without it for Firefox 4. Does that mean that in-content UI will not be chromeless if app tabs are not chromeless? And Peter, I think Mike was talking about the anchors for the doorhangers rather than the doorhangers themselves. I have to have something to hang the doorhangers onto, in a manner of speech. Also, the hotkey needs to be explicit. I think the Firefox menu is a fine place to put the option of restoring the UI if needed, but then again, as I said before, I don't think app tabs should be chromeless by default. Because of the issues Mike raised and a few others.

(In reply to comment #8) > (In reply to comment #6) > > Minusing, the UX team can renominate if they feel like it must block a release, > > but I think we can live without it for Firefox 4. > Does that mean that in-content UI will not be chromeless if app tabs are not > chromeless? No, AppTabs has nothing to do with In-Content UI. > And Peter, I think Mike was talking about the anchors for the doorhangers > rather than the doorhangers themselves. I have to have something to hang the > doorhangers onto, in a manner of speech. Site's favicon on AppTab.

I would renominate this for blocking, especially if the AOM, etc are meant to be chromeless. As for bring toolbars back, ultimately that's something users should've thought about when granting sites permission to make changes to browser/tab, it most certainly doesn't need a hotkey, but it should definitely be in the site preferences. It would be a real disappointment to ship 4.0 without this.

(In reply to comment #10) > It would be a real disappointment to ship 4.0 without this. Indeed. I was really looking forward to chromeless AppTabs, and I still am.

I think without this and other promised functionality App Tabs are essentially Pinned Tabs. Essentially what we'd like is that this ships in time for the next beta so as that websites can start to implement the backend to fully utilise the technology.

(In reply to comment #9) > Site's favicon on AppTab. Oh, that's neat. Where did you read that?

(In reply to comment #13) > (In reply to comment #9) > > Site's favicon on AppTab. > Oh, that's neat. Where did you read that? Nowhere, it's my idea.

Perhaps the app tabs should have the option to hide the nav bar on by default and the user can toggle by right click or a very thin line under the tab strip

Through a combination of addons today, I have "app tabs" already and have found chrome to be incredibly useful for some sites. While Gmail and Greader are designed so that you don't need additional navigation, Google FastFlip and Facebook would cause me to need to see back/forward and the URL bar. Also, I would always want to have my search box and my Read It Later button which would launch new tabs. Removing chrome would overly complicate things and cause the user to have a different experience just because they wanted something to be an App Tab. Please keep in mind that not every App Tab is an App like Gmail.

That is why we have bug 536267.

Given the implementation from bug 587908, how/where will the target of a hovered hyperlink be displayed for chromeless (i.e. locationbar-less) tabs?

This behavior should be an option which can be set individually for each app tab. The address bar / bookmark-bar are a waste of vertical space in most cases, which is bad, especially for small wide screen displays. It's also bad if you're developing web applications using FireBug. I have to resize FireBug every two minutes because otherwise, I wouldn't be able to reach some UI-components.

Is there any data on how the current "app tabs" are being used in the betas? I myself never run web apps in "app tabs", but use them rather as pinned tabs (they lack the ability to actually being pinned, but that is another issue). If people use these tabs as start pages and then navigating to other pages from there, isn't there a security issue involved not always showing the current URL and a usability issue not showing the back and forward buttons? (Home button could act as back to pinned tab startpage in this use case btw)

Oh, and both Opera and Chrome use the name "Pinned tab" since this facilitates for a variety of uses, not only designated to be used for web apps as Firefox' "App tab" indicates.

If you want to make them chromeless _by default_ it shouldn't be allowed to change the current domain. Otherwise criminals could, for instance, fake a location bar using JavaScript and show a faked online-banking page below. Even experienced users would get into this kind of trap, I think. This can be avoided by always opening pages with domains different from the current one inside new non-app tabs. In my opinion, this restriction would emphasize the difference between pinned and app tab. The remaining problem about this is how to handle iframes with content from a different domain.

(In reply to comment #23) > This can be avoided by always opening pages with domains different from the > current one inside new non-app tabs. Bug 608791 implemented this functionality for links.

Will this make into FX4?

(In reply to comment #25) > Will this make into FX4? No, just have a look at the "blocking2.0" flag or target milestone field.

Great, another feature I was looking for were cut off.

This can be handled with a userstyle or extension if it really isn't going to make it. That said, this is quite a large ask. There are UI issues. App Tabs are still tabs and so still open to phishing. By hiding the entire chrome we also lose the ability to URL preview. Most users will use App Tabs for things like Email, facebook, twitter and other social networking staples. All of which are targeted for phishing. It's been to take this slowly and ensure that users are safe than to implement it badly and have to back away from the entire concept.

Maybe that the url bar should remain (but greyed out) and other controls could be removed ?

It needs to be that only the domain name that the user clicks to make into an app tab will appear in that tab. If the user clicks out or is redirected to another domain it should appear in a regular tab and with the navigation bar showing.

Use this add-on until this land: http://soapyhamhocks.deviantart.com/#/d329hfg

(In reply to comment #30) > It needs to be that only the domain name that the user clicks to make into an > app tab will appear in that tab. If the user clicks out or is redirected to > another domain it should appear in a regular tab and with the navigation bar > showing. The user should get advance warning of where they're travelling to. (In reply to comment #29) > Maybe that the url bar should remain (but greyed out) and other controls could > be removed ? That's not really feasible and kind of defeats the point of chromeless. I filed bug 625008, but I'm not even sure if that's feasible.

We still want to do this, the main limiting factor is the time it will take to implement. We also need to attach mockups for all of the small issues this would create (tooltips for navigation target, getting notifications to hang off of the tab, creating a panel based UI with controls like reload and refresh when you click on the tab again, etc.)

dupe of bug 644721?

I'm not sure if any Test Pilot studies would show you if this is a common use case but I can tell you from personal experience I use my bookmark bar quite a lot to open new tabs from my app tabs. Just want to make sure devs are considering it. If it is an uncommon use case then I'm sure there'll be a work around.

The default UI we're designing against has the bookmarks toolbar turned off by default. But users who have turned it back on (or already had a lot of bookmarks stored on it), may decide to turn on tool bars for their app tabs as well.

(In reply to comment #34) > dupe of bug 644721? Indeed.