Closed Bug 536267 Opened 15 years ago Closed 12 years ago

Inform site if it is running in an App Tab

Categories

(Firefox :: General, enhancement)

Product:
Firefox
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: deprecationmail, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.3a1pre) Gecko/20091220 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.3a1pre) Gecko/20091220 Minefield/3.7a1pre

I haven't yet seen a bug or any kind of implementation of App Tabs, but when I saw the mock-ups I figured that it might be good to "inform" the site that it is running inside an App Tab, and therefore allow it to adjust it's navigation, for example.

I'm not an expert at the area, but I think HTTP headers could be used. Other ways would be to have -moz CSS (and JavaScript) to allow for special styling in App Tab mode, but that would turn this into something quite advanced.

Reproducible: Always
Version: unspecified → Trunk
Blocks: pinnedtabs
We don't seem to be alerting sites that they're being run in a Prism. I don't see the benefit of telling sites what they're running as. After all, if it's a true web application, things like navigation style won't be an issue.
I can see the merits of this. For example, let's say you're using Gmail on Prism. As you know, in the header of Google's site is a bar with links to other Google services like Docs. If you were in Prism and clicked on "Docs", the Google Docs page would load in the same window, even though it's a different application.

There needs to be some way for it to be opened in a new tab/window, rather than load in the same one.
Can we not just force links above the current directory to open a new tab?

e.g. site/app-folder-01/links -> open in same window
site/app-folder-02/links -> open in different tab

I say this because I'd like the browser to do the leg work here instead of hoping that sites will suddenly conform. For example, you have Yahoo mail which is huge in certain parts of the world and yet (and there's a lot of discussion here) it refuses to support Opera properly. We can't really depend on sites to do things and I don't think we should be hoping that they're so willing to weight down their websites. Instead App tabs should just enforce certain behaviours on links.

How is Chrome handling it with their version of Prism and GMail?
(In reply to comment #3)
> Can we not just force links above the current directory to open a new tab?

That would be a much better solution, yes.
(In reply to comment #3)
> Can we not just force links above the current directory to open a new tab?
> 
> e.g. site/app-folder-01/links -> open in same window
> site/app-folder-02/links -> open in different tab
> 
> I say this because I'd like the browser to do the leg work here instead of
> hoping that sites will suddenly conform. For example, you have Yahoo mail which
> is huge in certain parts of the world and yet (and there's a lot of discussion
> here) it refuses to support Opera properly. We can't really depend on sites to
> do things and I don't think we should be hoping that they're so willing to
> weight down their websites. Instead App tabs should just enforce certain
> behaviours on links.
> 
> How is Chrome handling it with their version of Prism and GMail?

Indeed, we should/could modify behavior in some cases, but these things does not exclude each other. We should give sites the option to implement their own behavior for App Tabs if they want to.
(In reply to comment #5)
> Indeed, we should/could modify behavior in some cases, but these things does
> not exclude each other. We should give sites the option to implement their own
> behavior for App Tabs if they want to.

Agreed. Where to open links is a very specific example. There are plenty of other cases where this would be useful; such as knowing not to display certain UI elements that are related to browsing (such as Google's top toolbar), rather than related to a more "app" experience.
Google display their toolbar in their own version of Prism, thus I doubt they'll disable it for us. If they were gonna do it, they'd have done it for themselves first and foremost.

I think you're putting too much stock in where the web application market currently resides and the power that Mozilla has over it. People are sick of modifying sites for IE6. They're not about to start doing the same thing for Mozilla's app tabs. If anything get the implementation down and then move forward from there on some sort of standard that works across all browsers and benefits everyone.
(In reply to comment #7)
> I think you're putting too much stock in where the web application market
> currently resides and the power that Mozilla has over it. People are sick of
> modifying sites for IE6. They're not about to start doing the same thing for
> Mozilla's app tabs. If anything get the implementation down and then move
> forward from there on some sort of standard that works across all browsers and
> benefits everyone.

I don't think you understand what this bug is about.

1. If anyone, you are the one suggesting a new default behavior, in the opening of links.

2. Implementing this wouldn't do a thing to sites that doesn't want to do something related to App Tabs. The only thing this bug would add is a way for the sites that WANT to change their site to compensate for it running in an App Tab. It would not affect how other browsers render the site.
(In reply to comment #8)
> (In reply to comment #7)
> > I think you're putting too much stock in where the web application market
> > currently resides and the power that Mozilla has over it. People are sick of
> > modifying sites for IE6. They're not about to start doing the same thing for
> > Mozilla's app tabs. If anything get the implementation down and then move
> > forward from there on some sort of standard that works across all browsers and
> > benefits everyone.
> 
> I don't think you understand what this bug is about.
> 
> 1. If anyone, you are the one suggesting a new default behavior, in the opening
> of links.

I'm of the opinion that this bug is fruitless as the benefits are menial and reproducible within the browser. Thus if the browser can do the legwork, why would hope that the site will do it?

> 2. Implementing this wouldn't do a thing to sites that doesn't want to do
> something related to App Tabs. The only thing this bug would add is a way for
> the sites that WANT to change their site to compensate for it running in an App
> Tab. It would not affect how other browsers render the site.

You are hoping that the browser will render the site differently though. You're hoping that the browser will flag the site and it'll disable or enable certain aspects. How many sites are going to implement a special design for a browser that's not heavily leading in the market? I mean Firefox doesn't even have Group Policy management yet.

Thus I'm of the opinion that informing sites if it is running in an App Tab is pointless at the present moment in time. My apologies if this is the wrong place to express that or if I done it poorly. But I most certainly believe there should be some data to support such a request from websites (for App Tab version of their sites) and you won't be able to provide that until you implement App Tabs and get some usage data.

I mean by all means do it, but there should be a SMART objective for such a goal and I don't believe one exists here.
You have a point, but since the idea of App Tabs is to hide a lot of Firefox UI, like the toolbar (containing back/forward/reload buttons etc), a site might want to add their own version of these controls. With another browser, or when out of App Tabs, controls like those won't be needed, and should not be shown. Without these controls, a site might even turn unusable if it isn't constructed as an application, when running inside an App Tab.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is hiding the UI of App Tabs decided on already? I don't think it is.

I voiced my opinion about why hiding the UI of App Tabs is not a good idea at all: http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/0dd173f268a16f34#

As for this bug in particular, I think that, if Firefox does tell the site it's running on an App Tab, it should tell him whether it's running with a browsing UI or not. I don't think it's necessary to implement this feature, but if it's easy to do and light on the code, why not?
(In reply to comment #10)
> You have a point, but since the idea of App Tabs is to hide a lot of Firefox
> UI, like the toolbar (containing back/forward/reload buttons etc), a site might
> want to add their own version of these controls. With another browser, or when
> out of App Tabs, controls like those won't be needed, and should not be shown.
> Without these controls, a site might even turn unusable if it isn't constructed
> as an application, when running inside an App Tab.

Then like some1 stated earlier it not a real web app then.
if you decide to make apptabs chromeless or make them inform anyone - users will use userstyles to get chrome back.
if you decide to make apptabs report anything to the site - we will find a way to forge http-headers to cut that info.
but please, don't change any behavior of clicks on links in the apptabs - I bet it would be very uncomfortable to use and until a new add-on will be written that will fix it back - many users will stop using apptabs.
or there is meant to be some difference between apptabs and pinned tabs? is apptabs the same what project prism is about?
(In reply to comment #13)
> if you decide to make apptabs chromeless or make them inform anyone - users
> will use userstyles to get chrome back.
App Tabs are meant for web apps, not just generic websites. This is what this whole project is about.
> if you decide to make apptabs report
> anything to the site - we will find a way to forge http-headers to cut that
> info.
We might decide to report it using JavaScript, in which case, you'd be looking at navigator.mozAppTab or something like that. To me, JavaScript seems to be the simplest option here.
> but please, don't change any behavior of clicks on links in the
> apptabs - I bet it would be very uncomfortable to use and until a new add-on
> will be written that will fix it back - many users will stop using apptabs.
We want to keep the right web app in the app tab. That is (partially) bug 575561.
> or there is meant to be some difference between apptabs and pinned tabs? is
> apptabs the same what project prism is about?
App Tabs are pinned tabs. Prism and App Tabs are similar in their ideas, but App Tabs are in the browser.
(In reply to comment #15)
> App Tabs are meant for web apps, not just generic websites. This is what
> this whole project is about.

> App Tabs are pinned tabs. Prism and App Tabs are similar in their ideas, but
> App Tabs are in the browser.

And therefore AppTabs are NOT pinned tabs!
(In reply to comment #15)
> We might decide to report it using JavaScript, in which case, you'd be
> looking at navigator.mozAppTab or something like that. To me, JavaScript
> seems to be the simplest option here.

I think it also makes sense to support a CSS media query for this, so the presentation of a webapp may adapt, in addition to the behaviour.
We enable special functionality for app tabs, e.g. flashing the tab when the "page title" changes, and the content might need to react to that - e.g. my in-tab download manager add-on updates the page title with the percentage of downloading done, which makes it flash constantly while downloading when it's set as an app tab, which I naturally want to avoid... ;-)
So, to implement the JS side of this, all that would be needed would be to add corresponding attributes/events to the webcontent's document element in tabbrowser.xml's pinTab and unpinTab section, right? ( http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#228 )

That doesn't sound too hard, and I'd be willing to try to do it, but I can't figure out what would be the easiest way to go from the XUL tab element that's present in the existing code to the corresponding document element for that XUL tab.

Any pointers?
Would something like this work?

this.getBrowserForTab(aTab).contentDocument.setAttribute("isPinned", true);

I'm not sure whether that contentDocument is the actual document for the tab's content, or if that's some other document for the browser that webcontent can't read from.
(In reply to comment #20)
> this.getBrowserForTab(aTab).contentDocument.setAttribute("isPinned", true);

Regardless of whether it works, do not modify the content DOM from chrome like that. Chrome code should not be messing with DOM attributes.
In that case, couple other questions.

The code already sets an "isAppTab" thing for the docShell of the tab's browser element. Can that be exposed to content somehow?

If not, where else would be the best place to expose the attribute to webcontent without it being on the document element?
I think things like that are usually exposed to content via the navigator object.
(In reply to Peter Henkel [:Terepin] from comment #16)
> (In reply to comment #15)
> > App Tabs are meant for web apps, not just generic websites. This is what
> > this whole project is about.
> 
> > App Tabs are pinned tabs. Prism and App Tabs are similar in their ideas, but
> > App Tabs are in the browser.
> 
> And therefore AppTabs are NOT pinned tabs!

They are as of bug 769101.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.