67175 - drag link/proxy icon to sidebar tab to insert new panel

Status: NEW

(SeaMonkey :: Sidebar, enhancement)

Description

[Jesse Ruderman]

From [e-mail] in bug 50063:

>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.

Neat idea.  Dragging to tabs or to the top of the sidebar (above the first tab) 
should give an "Add to sidebar?" dialog.

Should the user also be given a chance to specify a title for the new panel?  
Many webpage titles aren't designed to be used as sidebar panel titles.

Comment 1

[Ben Bucksch (:BenB)]

> Dragging to tabs or to the top of the sidebar (above the first tab)
> should give an "Add to sidebar?" dialog.

Right.

> Should the user also be given a chance to specify a title for the new panel?

Yes. IMO, this should be added to the "Add to sidebar?" confirmation dialog,
since the user might not like the title of a specifially designed sidebar panel
either. It should have the author-specified title as default, tough.
(Or is there a way to change the title afterwards? I haven't found one quickly.)

Comment 2

[Matthew T (active 1999-2002)]

You have the same problem as you have in bookmarks -- a tradeoff between the 
convenience of adding an item quickly (without a dialog), and being able to 
edit details when adding it (by using a dialog). See also bug 47599.

Comment 3

[Ben Bucksch (:BenB)]

We need a dialog anyways, for confirmation.

Comment 4

[Matthew Wilson]

Adding a panel via window.sidebar.addPanel always requests confirmation, but 
does not give the ability to change the title.

Comment 5

[Matthew Wilson]

Attachment: Proposed patch

Comment 6

[Matthew Wilson]

The above patch should allow you to drag a URL to the "My Sidebar" tab at the
top of the sidebar panel. It will then be added (after confirmation).

Cc'ing ben, because a lot of the current drag and drop code has "XXX - WARNING -
XXX" comments in it.

Comment 7

[Matthew Wilson]

The attached patch does not seem to work any longer.

Comment 8

[Matthew Wilson]

Attachment: Revised patch

Comment 9

[Matthew Wilson]

Attachment: Revised patch again (text/javascript should be application/x-javascript)

Comment 10

[timeless]

in olden times, <a href=foo>was</a> valid.  a quick read of your code indicates 
you don't like it.

<a href="http://foo/bar'baz/"> also appears to be squished

Comment 11

[Matthew Wilson]

Good point (not to mention <a target="whatever" href="url"> and others...) But
at the moment I can't find anything to drag which gives a flavour of text/html,
so that code isn't being executed. (Dragging from the main content window is
giving me text/x-moz-url). So unless anyone can tell me how to do this, I will
submit a revised patch without this section of code.

Comment 12

[Samir Gehani]

Cool feature.  Todd, German, what do you'll think?  Would this be a high
priority for Netscape to contribute?

Comment 13

[Todd Pringle]

This does sound pretty cool, but not a priority, IMO.  Many users never fully
discover DnD functionality and this would be a relatively complex concept for
the average end user to understand.  We could do some things to help them, but
we need to focus our efforts for now on more basic improvements to Sidebar
behavior/functionality.  That's my 2 cents anyway.

Comment 14

[Matthew Wilson]

Just to note that this patch no longer works correctly.

Comment 15

[Matthew Wilson]

Trying again, it seems to work OK in an optimised build, but there are some
nasty assertions in a debug build.

Comment 16

[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 17

[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 18

[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 19

[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 20

[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 21

[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 22

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 23

[Karsten Düsterloh]

Valid RFE.