50063 - Ability to enter custom URL for sidebar tab

Status: RESOLVED WONTFIX

(SeaMonkey :: Sidebar, enhancement)

Description

[Dan Nunn]

It sure would be nice to be able to add any URL to the sidebar panel. What I
mean by this is, in the Customize Sidebar dialog, somewhere there would be a
button (or anything else deemed appropriate) to add any URL (and title) to the
sidebar, manually. Sure, this can be easily done using the Javascript call, but
not everyone (read: end-users) knows of this. Besides, it'd be handy. Any thoughts?

Comment 1

[Ben Bucksch (:BenB)]

Agreed, good idea.
Advantages:
- Users couls use a normal (slim) webpage as sidebar.
- User could write their own local sidebar panel without having to write the JS
function.
- It would be easier to fix bad JS from the content provider (just occured for
me with Dino! <http://dino.mozdev.org>).

-> default owner. slamm is gone (I've been told).

Comment 2

[Matthew Wilson]

This looks like it could be implemented with a fairly simple patch.

However, what should the UI be for this feature? Should there be two textboxes
(Title, URL) and a button (Add this URL) on the "Customize Sidebar" window
(below "Available Tabes", maybe)? Or should "Customize Sidebar" have a button
"Add Specified URL", which brings up another window with the textboxes?

Comment 3

[Matthew Wilson]

Adding mpt to cc list for opinions on UI issue (following advice on #mozillazine)

Comment 4

[timeless]

the easiest approach for a ui is to just make the sidebar a folder in 
bookmarks.  But that should be discussed in another bug.

Comment 5

[Ben Bucksch (:BenB)]

> the easiest approach for a ui is to just make the sidebar a folder in
> bookmarks.

Good idea. Reuses code and UI patterns.

> But that should be discussed in another bug.

Why?

Comment 6

[Matthew T (active 1999-2002)]

> Should there be two textboxes (Title, URL) and a button (Add this URL) on the
> "Customize Sidebar" window (below "Available Tabes", maybe)? Or should
> "Customize Sidebar" have a button "Add Specified URL", which brings up another
> window with the textboxes?

The latter, because users would naturally press Enter after entering the URL. So 
if you just put this UI into the `Customize Sidebar' dialog, where pressing 
`Enter' closes the Customize Sidebar dialog, users would keep closing the dialog 
by mistake (without adding the URL at all).

Also, you should be able to drag a link/URL to the tabs (as opposed to the 
sidebar content) in the open sidebar, to create a tab in the position you drop 
the URL.

> the easiest approach for a ui is to just make the sidebar a folder in
> bookmarks.

Tempting, but bookmarks and sidebar panels are conceptually very different things 
-- having to go to `Manage Bookmarks' in order to customize sidebar panels would 
make about as much sense as having to go to `Start' in order to Shut Down.

Comment 7

[Jesse Ruderman]

>Also, you should be able to drag a link/URL to the tabs (as opposed to the 
>sidebar content) in the open sidebar, to create a tab in the position you drop 
>the URL.

I've split off as bug 67175.

Comment 8

[Matthew Wilson]

Attachment: Patch. Excludes new file addurl.xul

Comment 9

[Matthew Wilson]

Attachment: New file for patch, xpfe/components/sidebar/resources/addurl.xul

Comment 10

[Matthew Wilson]

I believe the attached files add this functionality. Apologies for the two
separate files, I couldn't get "cvs diff" to list the contents of the new file.

Comments welcome.

Comment 11

[timeless]

+    <button id="add-url" value="Add specified URL" 
oncommand="OpenAddURLWindow()"/>
please use:
value="&sidebar.customize.addurl;"

new files should be under the MPL unless you are employed by netscape, see 
www.mozilla.org/MPL/boilerplate-1.1/

<script language="javascript" src="chrome://global/content/strres.js"/>
<script language="javascript" 
src="chrome://communicator/content/utilityOverlay.js"/>

<html:script>

don't use <html:script>, instead use <script>
don't use language="javascript", instead use type="text/javascript"

in the future, with cvs privs, you can do: cvs add file && cvs diff -N -u file 
to get diffs for new files.

for now, you can either attach diffs against your new file or attach a 
replacement.

Thanks for working on this.

Comment 12

[shrirang khanzode]

spam : changing qa to sujay (New Sidebar QA)

Comment 13

[Matthew T (active 1999-2002)]

While you're putting the button text into a properties file, please change it 
from `Add specified URL' to `Add Address as Tab...'

Comment 14

[Ben Bucksch (:BenB)]

Why Address and not URL?

I'd argue for "Add tab from URL...", since you are not adding the URL, but the
*page* at the URL, as tab.

Comment 15

[timeless]

why not Make tab from URL?

Comment 16

[Matthew T (active 1999-2002)]

> Why Address and not URL?

Because the overwhelming majority of the Web browser users I talk to know what an 
address is (in relation to the Web), but have no idea what an URL is.

The `From' suggestion is valid -- but on reflection I think the button would be 
most obvious if it just said `New ...'.

Comment 17

[Matthew Wilson]

Sorry, but I'm not convinced that "New..." can be described as obvious.

Comment 18

[Matthew Wilson]

mpt, I presume you would also prefer "Address for new sidebar panel" instead of
"URL for new sidebar panel" on the window?

Comment 19

[Matthew T (active 1999-2002)]

Correct.

Comment 20

[Matthew Wilson]

Attachment: Revised patch

Comment 21

[Matthew Wilson]

Attachment: Revised new file addurl.xul

Comment 22

[Matthew Wilson]

For the addurl.xul patch, <textfield> should now be <textbox>

Comment 23

[Matthew Wilson]

Attachment: New file addurl.xul with <textbox> not <textfield>

Comment 24

[matt]

Matthew,

The code looks fine.  Make sure you have the right makefiles for this.
I saw your comments about not putting it in the customize dialog.  What happens 
if we put it in a dialog. that inserts it into the RDF on the right tree.  That 
will be more work though.

r=matt

Comment 25

[timeless]

please use type="application/x-javascript"
r=timeless for that change

did no one object to this:
  <separator/>

Comment 26

[Matthew Wilson]

timeless, would you prefer <separator orient="horizontal" class="thin"/> ? Or
are you saying it is unnecessary?

Comment 27

[timeless]

the latter? however perhpas you could attach a picture?

Comment 28

[Matthew Wilson]

Attachment: New window without <separator>

Comment 29

[Matthew Wilson]

Attachment: New window with <separator>

Comment 30

[Matthew Wilson]

Matt, I think the makefiles (included in the patch) are OK.

timeless, including <separator> gives more spacing between the input fields and
the OK/Cancel buttons (which I prefer). What do you think?

And (oops) in the attached patch,
+    <button id="add-url" value="&sidebar.customize.addurl;" ...

should be
+    <button id="add-url" label="&sidebar.customize.addurl;" ...

in the change to customize.xul. New patch to follow.

Comment 31

[Matthew Wilson]

Attachment: Revised patch (just changes <button value="..."> to <button label="...">

Comment 32

[german]

Sorry for chiming in late but I don't think this is a very suitable solution 
for Netscape users, but probably more for the Mozilla type tinkerer. Two 
thoughts:
- Typing in a URL is a very inconvenient thing to (especially without 
autocomplete etc). Most content for sidebar is/will be offered through a button 
on a page
- I understand the desire to have custom content at the user's discretion above 
and beyond what's offered, but content added that way has never been designed 
for the sidebar (width, structure, interaction). I think something like 
http://www.livesidebar.com is a better solution to this problem, letting users 
pick snippets of a page and adding those to the sidebar.
Thinking this further I can see a day where users would simply select a portion 
of an arbitrary page on the web, and we'd extrapolate structure and location 
using the good old DOM, and adding that to the sidebar.

Comment 33

[timeless]

<title>Create Sidebar Tab</title>
<label>Name:</label><editbox/><br/>
<label>Address:</label><urlbar/>
<p><ok><cancel></p>
[Yes, this is not valid xml xul or html, but it should be human readable]
You're right about the space between the address and the buttons.

However, the ? icon doesn't seem useful.  The ellipsis do _not_ belong in the 
dialog title -- they would belong in the menu item/button that creates the 
dialog.

German is right that we should use the autocomplete widget.

Personally, you're duplicating way to many words, please consider my wording.  
I would make the dialog narrower (and my changes make it shorter).

Comment 34

[Matthew Wilson]

Attachment: Revised patch (new entities as suggested by timeless)

Comment 35

[Matthew Wilson]

Attachment: Revised addurl.xul (uses new entities, narrower, uses autocomplete for URL)

Comment 36

[Matthew Wilson]

New files attached, I note however that autocomplete is broken at the moment 
(bug 78771)

Comment 37

[Matthew Wilson]

Attachment: New addurl.xul (keeping up(?) with XUL syntax changes)

Comment 38

[m_mozilla]

in the meantime, use this bookmarklet... I do and it works just dandy.

I've changed by normal "start page" to have target="_content" so I don't have to
drag links from the sidebar to the main page, and now I've got my own sidebar
without having to know how to create sidebars.

forget where I found this bookmarklet, or I'd give credit. I leave it in my
personal toolbar labeld "grab" ...

javascript:(function(){var x; x=prompt('Sidebar title:', document.title); if (x
!= null) { window.sidebar.addPanel(x,location.href,''); } })();

-matt

Comment 39

[Boris Zbarsky [:bzbarsky]]

The patch in this bug does not apply cleanly... any chance of getting an updated
patch out?  Is the addurl.xul current with XUL syntax?  :)

If you update the patch, please add this bug as a dependency to bug 123569

Comment 40

[Blake Ross]

reassigning matt's old bugs.

Comment 41

[Allan]

MSIE on Mac already does this, and perfectly, via its Page Holder feature. The
UI is simplicity itself: Click page holder tab on left, the sidebar opens. Three
buttons: "Add page to holder" "Show links" "Favourites". 

Clicking "add page to holder" copies the currently viewed page into the sidebar,
Showlinks lists only the links on the page, and the favourites is a sub menu of
bookmarks, plus an "add page to pageholder favourites" entry.  

They're stored as a sub-folder of the main bookmarks. It doesn't matter what the
content of the page is, it's reformatted to the (resizable) bar, and its links
re-targeted to the main window.

I love this, and it's all that keeps using MSIE. Can it be done?

Comment 42

[Max Alekseyev]

Does this RFE deal also with editing/revising existing Sidebar urls/titles?

Comment 43

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 44

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 45

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 46

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 47

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 48

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 49

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 50

[Robert Kaiser]

I don't see the SeaMonkey team working on this in anything but my wildest dreams where we have hundreds of people working on the code, so I'll be honest and WONTFIX this. Please work on this as a SeaMonkey 2 add-on and ask for inclusion in the main code only if that if getting widely adopted.