Closed Bug 266273 Opened 20 years ago Closed 12 years ago

dnd or copy/paste of bookmark items fails if dragging between bookmark managers

Categories

(SeaMonkey :: Bookmarks & History, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: bug, Unassigned)

Details

(Keywords: assertion, Whiteboard: [2012 Fall Equinox])

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

if you try to move/copy bookmark items between two mozilla processes (different
uids) by drag and drop (from/to bookmark manager), the target item is empty.

Reproducible: Always
Steps to Reproduce:
1.as user foo, open mozilla and its bookmark manager.
2.in a terminal, do: "xhost + localhost; su - bar", and then "export
DISPLAY=:0.0; mozilla&" and open the bookmark manager.
3.drag any bookmark item (also folders) from one bookmark manager to the other.

Actual Results:  
an empty bookmark item appears in the bookmark manager where you drop.
_sometimes_, you get:
"Gtk-CRITICAL **: file gtkdnd.c: line 623 (gtk_drag_get_data): assertion `widget
!= NULL' failed."
in the drop target console.


Expected Results:  
copy the bookmark item.

dropping foo's bookmark item into bar's emacs window produces the bookmark's url.
dropping bookmark folders or multiple bookmarks into emacs does not work.

I am using libgtk-1.2.so.0.9.1.
> if you try to move/copy bookmark items between two mozilla processes (different
> uids) by drag and drop (from/to bookmark manager), the target item is empty.

discovered that the dropped items are also empty if you dnd between two sessions
(different profiles, hence different mozilla processes, but same uid), so a
permission issue in gtk can probably be excluded.

Furthermore, items are also empty when using copy/paste, not only drag/drop. The
two processes don't seem to communicate their clipboard information. Is this a
feature or a bug? Should this be handed to bookmark or ipc component?

-> changed summary and component
Component: XP Apps: Drag and Drop → Bookmarks
Summary: dnd fails if dragging to different user id → dnd or copy/paste of bookmark items fails if dragging between bookmark managers
Product: Browser → Seamonkey
Assignee: nobody → p_ch
QA Contact: bookmarks
Version: Trunk → 1.7 Branch
Interestingly, drag&drop between two processes from a bookmark manager
(including the personal toolbar) to a tab in the other process works properly.

But dragging to a bookmark manager in that other window fails in the way described.

(This behavior holds even if the two Mozilla processes are on two machines,
displaying on the same X server, i.e. I can drag to a tab to load the bookmark,
but not to a bookmark manager if the destination is owned by a different process.)

I'm currently using Mozilla 1.7.6.
Additional testing reveals that dragging a URL between processes is no problem
if the source is a displayed HTML file, i.e. you can load your bookmarks.html
file into the browser and drag links across browser processes this way.
Dragging from the History sidebar or window also functions properly, but
dragging from the Bookmarks sidebar also fails.

Bookmark folders (regular and "group of tabs" varieties) don't seem to transfer
between processes at all.  Dragging multiple selected bookmarks to a tab (in
another process) loads the top-most bookmark of the selection into that tab.
It appears that the top-most selected item's URL is being sent in a
drag-and-drop to a tab or non-bookmark window.

IMHO, the failure to transfer folders and groups of selections between processes
could be considered "lack of a feature", but not a bug.  The failure to drag
from one bookmark manager to another in two different processes, when dragging
from a web page or a history manager to a bookmark manager in another process
works, _is_ a bug.  (In My Humble Opinion, of course.)
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This is still a problem in the 20050928 trunk, as described.
Reassigning as per Bug #32644
Assignee: p_ch → nobody
Mozilla/5.0 (X11; U; Linux i686; rv:1.9b5pre) Gecko/2008032401 SeaMonkey/2.0a1pre

got (gecko:8797): Gtk-CRITICAL **: gtk_drag_get_data: assertion `GTK_IS_WIDGET (widget)' failed

on  terminal also with 1.1.9rc, so confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: assertion
Version: 1.7 Branch → Trunk
Now only one instance of Bookmarks Manager available, also dragging bookmarks from it to browser window works without problems, so closing this
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Whiteboard: [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.