Closed Bug 1299352 Opened 3 years ago Closed 2 years ago

Cutting and pasting a folder in SeaMonkey's bookmarks fails.

Categories

(SeaMonkey :: Bookmarks & History, defect)

SeaMonkey 2.38 Branch
Unspecified
All
defect
Not set

Tracking

(seamonkey2.44 wontfix, seamonkey2.45 wontfix, seamonkey2.46 wontfix, seamonkey2.47 wontfix, seamonkey2.48 wontfix, seamonkey2.49esr wontfix, firefox51 unaffected)

RESOLVED DUPLICATE of bug 1378089
Tracking Status
seamonkey2.44 --- wontfix
seamonkey2.45 --- wontfix
seamonkey2.46 --- wontfix
seamonkey2.47 --- wontfix
seamonkey2.48 --- wontfix
seamonkey2.49esr --- wontfix
firefox51 --- unaffected

People

(Reporter: ant, Unassigned)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40
Build ID: 20160120202951

Steps to reproduce:

1. Open SM's bookmarks (ctrl-b hotkeys) in Windows.
2. Cut a folder inside.
3. Paste it to another area in bookmark to move it.



Actual results:

Cutting and pasting (mouse and hot keys) a places.sqlite's GUI bookmarks (ctrl-B)'s folder failed in my and others' SeaMonkey (SM) v2.4x web browsers in Windows. They do get cut, but pasting fail. I can undo to get them back. I also can drag and drop the folders too. Cut and paste doesn't work. 

In 64-bit Debian with 64-bit SM's bookmarks, I cannot even cut even though the option is there.


Expected results:

The cut folder should be pasteable in the new bookmarks' area.

https://groups.google.com/forum/#!topic/mozilla.support.seamonkey/-8tv3Dj_wmY thread of others and talking about it.
REPRODUCIBLE with official en-US SeaMonkey 2.48a1  (NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Build 20160804000913  (Default Classic Theme) on German WIN7 64bit

a) also will fail:
a1) Drag and Drop as copy - paste with ctrl+mousebutton (no clone will appear at 
    target where mouse button becomes released)
a2) Drag and Drop with only mousebutton  (seems not to work reliably, but currently
    I am not sure. sometimes no clone will appear at target where mouse button 
    becomes released, but sometimes clone DOES appear.) 
b) Drag and Drop as cut and paste with shift+mousebutton will work
Status: UNCONFIRMED → NEW
Ever confirmed: true
c) Still worked fine with WIN SeaMonkey  2.37a2 Build identifier: 20150609235642
d) Already  REPRODUCIBLE with  en-US SeaMonkey  2.38  (Windows NT 6.1; WOW64;
   rv:41.0)  Gecko/20100101 Firefox/41.0 Build 20150923195647  (Classic Theme) 
   on German WIN7 64bit
Keywords: regression
OS: Unspecified → All
Version: SeaMonkey 2.40 Branch → SeaMonkey 2.38 Branch
e) NOT reproducible with FF 51.0a1 (2016-08-19)
Summary: Cutting and pasting SeaMonkey's places.sqlite's bookmark's folder to move fails. → Cutting and pasting a follder in SeaMonkey's bookmark's fails.
Duplicate of this bug: 1331189
Summary: Cutting and pasting a follder in SeaMonkey's bookmark's fails. → Cutting and pasting a folder in SeaMonkey's bookmarks fails.
Maybe this is related: I'm prone to accidental folder drags while the bookmarks menu is open. The result has been disappearance of the accidentally dragged folder. Undo of the instinctive subsequent drop has never succeeded to put back the dragged folder. When I've noticed this to happen, I shut down SM and restore places.sqlite then reopen. Today I discovered a copy of a folder once lost in an adjacent folder. Current SM version is Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.1; Build ID: 20171002000000 from the openSUSE 42.3 repo, and DE is KDE3.
It looks like this bug is with the copy part from the bookmarks.

I did the following test:

"Installed" two SeaMonkeyPortable versions:
2.33.1 and the latest, 2.49.1
Coping a folder from 2.33.1 and pasting it in the 2.49.1 worked as expected:
The folder and its content bookmarks were copied to the 2.49.1 bookmarks manager.

Doing the other way around, coping from 2.49.1 to 2.33.1 did not work:
Nothing was pasted into the bookmarks manager
The places api changed too much and the needed fixes won't make it into 2.49.x. Fixed in Bug 1378089.
Duplicate of bug: 1378089
Duplicate of this bug: 1463664
You need to log in before you can comment on or make changes to this bug.