Ability to enter custom URL for sidebar tab

RESOLVED WONTFIX

Status

--
enhancement
RESOLVED WONTFIX
18 years ago
9 years ago

People

(Reporter: thedannunn, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 7 obsolete attachments)

(Reporter)

Description

18 years ago
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

18 years ago
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).
Assignee: slamm → matt

Updated

18 years ago
Keywords: helpwanted

Comment 2

18 years ago
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

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

Comment 4

18 years ago
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

18 years ago
> 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

18 years ago
> 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

18 years ago
>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

18 years ago
Created attachment 23992 [details] [diff] [review]
Patch. Excludes new file addurl.xul

Comment 9

18 years ago
Created attachment 23993 [details]
New file for patch, xpfe/components/sidebar/resources/addurl.xul

Comment 10

18 years ago
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

18 years ago
+    <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.
Keywords: patch

Comment 12

18 years ago
spam : changing qa to sujay (New Sidebar QA)
QA Contact: shrir → sujay

Comment 13

18 years ago
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

18 years ago
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

18 years ago
why not Make tab from URL?

Comment 16

18 years ago
> 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

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

Comment 18

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

Comment 19

18 years ago
Correct.

Comment 20

18 years ago
Created attachment 24306 [details] [diff] [review]
Revised patch

Comment 21

18 years ago
Created attachment 24307 [details]
Revised new file addurl.xul

Comment 22

18 years ago
For the addurl.xul patch, <textfield> should now be <textbox>
Keywords: review

Comment 23

18 years ago
Created attachment 32859 [details]
New file addurl.xul with <textbox> not <textfield>

Comment 24

18 years ago
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

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

did no one object to this:
  <separator/>

Comment 26

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

Comment 27

18 years ago
the latter? however perhpas you could attach a picture?

Comment 28

18 years ago
Created attachment 33158 [details]
New window without <separator>

Comment 29

18 years ago
Created attachment 33159 [details]
New window with <separator>

Comment 30

18 years ago
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

18 years ago
Created attachment 33160 [details] [diff] [review]
Revised patch (just changes <button value="..."> to <button label="...">

Comment 32

18 years ago
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

18 years ago
<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

18 years ago
Created attachment 33850 [details] [diff] [review]
Revised patch (new entities as suggested by timeless)

Comment 35

18 years ago
Created attachment 33851 [details]
Revised addurl.xul (uses new entities, narrower, uses autocomplete for URL)

Comment 36

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

Updated

17 years ago
Target Milestone: --- → Future

Updated

17 years ago
Attachment #33851 - Attachment is obsolete: true

Updated

17 years ago
Attachment #23992 - Attachment is obsolete: true

Updated

17 years ago
Attachment #23993 - Attachment is obsolete: true

Updated

17 years ago
Attachment #24306 - Attachment is obsolete: true

Updated

17 years ago
Attachment #24307 - Attachment is obsolete: true

Updated

17 years ago
Attachment #32859 - Attachment is obsolete: true

Updated

17 years ago
Attachment #33160 - Attachment is obsolete: true

Comment 37

17 years ago
Created attachment 52040 [details]
New addurl.xul (keeping up(?) with XUL syntax changes)

Comment 38

17 years ago
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
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

17 years ago
reassigning matt's old bugs.
Assignee: matt → sgehani

Comment 41

16 years ago
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?

Updated

16 years ago
Summary: [RFE] Ability to enter custom URL for sidebar tab → Ability to enter custom URL for sidebar tab

Comment 42

16 years ago
Does this RFE deal also with editing/revising existing Sidebar urls/titles?
Product: Browser → Seamonkey
Assignee: samir_bugzilla → nobody
Priority: P3 → --
QA Contact: sujay → sidebar
Target Milestone: Future → ---

Comment 43

9 years ago
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
Status: NEW → UNCONFIRMED

Comment 44

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

Updated

9 years ago
Status: UNCONFIRMED → NEW

Comment 50

9 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.