106129 - [RFE] Tab persistence when closed

Status: VERIFIED FIXED

(SeaMonkey :: Sidebar, enhancement, P1)

Description

[Samir Gehani]

Ability to persist tabs in the background once another tab is selected.

1. New nsISidebar.addPersistentPanel() API implementation.
2. Security dialog to warn user when tab is being added.

Comment 1

[Samir Gehani]

Current text:
-------------
"Add the tab '%title%' to the %name%?

Source: %url%"

Modified attempt:
-----------------
"Add the tab '%title%' to the %name%?

Source: %url%

Note: This is a request to add a "persistent" tab. Persistent tabs may continue
to run scripts or connect to the network even when the sidebar is closed."
Jatin,
Per our conversation, please modify and make more concise if possible.  Thanks!

Comment 2

[Ben Ruppel]

Perhaps calling them panels instead of tabs would be more appropriate.  I
confused them with the tabs of tabbed browsing myself.

Comment 3

[Jatin Billimoria]

My suggested wording:
"Note: You are adding a persistent tab, which remains connected to the network
even after you close the Sidebar."

Since we use the word "tab" regularly in the product and in Netscape online
help, it would be consistent to keep the work "tab "for an individual panel
within the Sidebar.

Comment 4

[Alex Bishop]

I'm not too sure most users will understand this "remains connected to the
network" business. How about:

Note: This is a persistent tab, which may send and receive data across the
Internet even when {My} Sidebar is closed.

Comment 5

[Jatin Billimoria]

I agree that Internet is a better word. Samir also feels that we need to mention
how scripting is used. Here is my suggested wording:

"Note: You are adding a persistent tab, which is connected to the Internet and
may use scripts to add functionality (such as displaying alerts) even after you
close the Sidebar."

Comment 6

[Alex Bishop]

Is mentioning scripts really neccessary? Most users probably don't understand
scripts and those that do would probably realise that if a tab is connected to
the Internet it can use scripts. Can't these details be put in the help file?

If mentioning scripts is required, how's this sound:

Note: This is a persistent tab, which may transfer data across the Internet or
run scripts (for example, to display an alert) even when {My} Sidebar is closed.

Jatin, when I read your latest suggestion it sounded as if all tabs can do when
the Sidebar is closed is run scripts.

Comment 7

[Jatin Billimoria]

Samir can vouch for the need to mention scripts. The use of "may" in the
sentence is intended to tell the user that a particular persistent tab may or
may not use scripts.

Comment 8

[Samir Gehani]

CC'ing Mitch.

Comment 9

[Alex Bishop]

"The use of 'may' in the sentence is intended to tell the user that a particular
persistent tab may or may not use scripts."

I never disagreed with the term 'may'. Both my suggestions use it. :-) It's just
that the bit about the Sidebar being closed seemed to only refer to scripts.
It's kind of hard to explain. Does this representation of how the sentence
seemed to break down to me make it any clearer?

[Note]: [You are adding a persistent tab], [which is connected to the Internet]
and  [may use scripts to add functionality (such as displaying alerts) even
after you  close the Sidebar].

Hmmm... probably not.

Comment 10

[Samir Gehani]

OK, Alex's latest verbiage sounds user friendly (even for non-sophisticated
users) and comprehensive.  Taking.

Comment 11

[Samir Gehani]

Oops, ignore last comment.  Still looking to refine verbiage.

Comment 12

[Alex Bishop]

Only verbiage I suggested was:

Note: This is a persistent tab, which may send and receive data across the
Internet even when {My} Sidebar is closed. <-- My favourite

- or -

Note: This is a persistent tab, which may transfer data across the Internet or
run scripts (for example, to display an alert) even when {My} Sidebar is closed.

The verbiage from my last comment was Jatin's. I was trying to (unsuccessfully)
demonstrate how the bit about stuff going on when the Sidebar is closed seems
(to me, anyway) to refer only to scripts and not data transfer (although I know
that wasn't the intention).

This English language thing is too limiting.

Comment 13

[Peter Trudelle]

This still sounds scary. I don't really know what it means for tabs to use
scripts;  what  are normal users to think? What does it mean, anyway?  If it is
just to display alerts, why don't we just say that? Although, of course most
users have no idea what an alert is. The  "add functionality" part sounds like
it could be installing other programs.  Also, if any third party software
installer told me it could be sending data over the Internet while closed, I'd
hit cancel so fast it would make your head spin. Does it really send data, or
only receive? BTW, why do we even need to use the word 'persistent'?
My take:  "The sidebar tab you are installing can receive data from the
Internet, and run scripts, even while the sidebar is closed. For example, the
Buddy List panel may detect when one of your buddies comes online, and alert you
to their presence."

Comment 14

[Samir Gehani]

(*) Yes, I agree that we don't need to mention the word 'persistent'.
(*) It can receive and *send* data (just as any HTML page can through JS or HTML).
(*) Mozilla users may not know what the Buddy List panel is.
(*) Some Netscape users may not know what the Buddy List panel is either.
(*) We call them tabs these days, not panels.  :o)
(*) I'd like to reserve the phrase "installing a tab" for when we actually
implement the tab install feature.  When we 'add' a panel we merely point to
something on the web.  

Thanks for all the comments.  Based on that I came up with this modified version.

Specimen A.
"The sidebar tab you are adding can tranfer data across the Internet and run
JavaScript even while {My} Sidebar is closed."

However, this is just an HTML page. I chatted with Mitch and we think it is
acceptable if we just tell the user that the webpage can remain active even
while the sidebar is closed.

Specimen B.
"The sidebar tab you are adding is a webpage that may remain active even while
{My} Sidebar is closed."

It's OK to say webpage since you can't add local chrome content through this API
(security measure).  How about we use specimen B?  If not, Mitch and I believe
specimen A should suffice.  This is after all only a webpage with the special
quality that its contents may not go away even when it is no longer visible. 
I'd venture to say that there are two classes of users w.r.t. webpages: those
that understand webpages can tranfer data and display alerts through JS and
those that don't.  For the users that do understand, they will comprehend the
implications as liad out in specimen B.  For users that don't understand, they
won't differentiate where an alert/window came from at all.  This is my argument
for choosing specimen B.  (This discussion is approaching overkill mode.)

Comment 15

[Mitchell Stoltz (not reading bugmail)]

My .02: I really think we should mention JavaScript in the warning.

Comment 16

[Alex Bishop]

After no thought and consideration, here's my latest suggestion. It even
mentions JavaScript :-). I've used the term 'persistent' because I think it will
help users distinguish between the two types of tabs if we give at least one of
them a name. I haven't used the term 'active' because I'm not sure it will mean
much to most users.

Note: This is a persistent tab, which may tranfer data across the Internet
and/or run JavaScript code even when {My} Sidebar is closed.

I'm not sure whether or not the word 'code' is actually neccessary. It's just
that "run JavaScript" doesn't sound quite right to me.

Comment 17

[Samir Gehani]

Plan on landing early in mozilla0.9.7.

Comment 18

[Samir Gehani]

Attachment: Implemented new window.sidebar.addPersistentPanel API and handling of persistent panels.

Comment 19

[Samir Gehani]

morse, please r.
dveditz, please sr.

Thanks.

Comment 20

[Stephen P. Morse]

Comment on attachment 58804 [details] [diff] [review]
Implemented new window.sidebar.addPersistentPanel API and handling of persistent panels.

r=morse

Comment 21

[Daniel Veditz [:dveditz]]

Comment on attachment 58804 [details] [diff] [review]
Implemented new window.sidebar.addPersistentPanel API and handling of persistent panels.

>+/*
>+    void addPanelEx(in wstring aTitle, in string aContentURL, 
>+                    in string aCustomizeURL, in boolean aPersist, 
>+                    in string aRegion, in unsigned long aExpiration);
>+*/

Is there a really, really good reason for adding this commented-out
method to the .idl?

>+/* decorate prototype to provide ``class'' methods and property accessors */

This comment is repeated from above but really goes with the section, not
any one method. It would have been clearer if there were some whitespace
after it in its previous use.

sr=dveditz with the above comment changes

Comment 22

[Samir Gehani]

OK, I'll lose the commented out method from the IDL (which was in the patch by
mistake) and remove the section-level comment blindly duplicated.  Thanks!

Comment 23

[Samir Gehani]

Checked in.

Comment 24

[Peter Trudelle]

*** Bug 114143 has been marked as a duplicate of this bug. ***

Comment 25

[sujay]

verified.