Closed
Bug 331905
Opened 19 years ago
Closed 19 years ago
copying folder puts the bookmarks in the target
Categories
(Firefox :: Bookmarks & History, defect, P2)
Tracking
()
RESOLVED
FIXED
Firefox 2 alpha2
People
(Reporter: mossop, Assigned: bugs)
Details
(Keywords: access, Whiteboard: swag: 2d)
Attachments
(1 file, 1 obsolete file)
|
19.23 KB,
patch
|
brettw
:
review+
|
Details | Diff | Splinter Review |
If I drag a folder in the places organiser and hold ctrl to copy it to the target, an empty folder of the right name appears at the target, and all the bookmarks in the source folder appear in the target folder, not in the newly created folder in the target as expected.
| Assignee | ||
Updated•19 years ago
|
Assignee: nobody → bugs
Priority: -- → P2
Target Milestone: --- → Firefox 2 alpha2
| Assignee | ||
Comment 1•19 years ago
|
||
happens for all copies, drag or not. accessibility bug too.
| Assignee | ||
Updated•19 years ago
|
Whiteboard: swag: 2d
| Assignee | ||
Comment 2•19 years ago
|
||
Patch does:
- makes sure the delete context menu item shows up on host folders (oops!)
- renames PlacesInsertSeparatorTransaction to PlacesCreateSeparatorTransaction just like all the other Create transactions
- reworks getFolderCopyTransaction significantly. This is for folder copies. The new one works like this:
When a folder is copied and pasted, it creates a clone of the folder hierarchy underneath it elsewhere in the bookmarks structure. The child content needs to be copied into the right places in the new structure. This means that the PlacesCreateItemTransactions that create the new URLs don't know at the time they are created what folder they're going into, because that folder hasn't been created yet! We need to be able to tell them later where they should be inserted. We do this by making the former private ._container property public, in .container.
Then we change _getFolderCopyTransaction to return a PlacesCreateFolderTransaction for the root folder, and attach to it the result of a depth-first walk of the folder's children.
Later, when PlacesCreateFolderTransaction's doTransaction method is called, it creates the folder then walks the child list and executes those transactions, creating child items, separators and subfolders.
Attachment #216797 -
Flags: review?(annie.sullivan)
Updated•19 years ago
|
Attachment #216797 -
Flags: review?(annie.sullivan) → review+
| Assignee | ||
Comment 3•19 years ago
|
||
Puts getRemoveFolderTransaction into the PlacesRemoveFolderTransaction ctor itself, rather than making the caller call it explicitly.
Attachment #216797 -
Attachment is obsolete: true
Attachment #216856 -
Flags: review?(annie.sullivan)
Updated•19 years ago
|
Attachment #216856 -
Flags: review?(annie.sullivan) → review+
| Assignee | ||
Comment 4•19 years ago
|
||
fixed branch and trunk
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 5•16 years ago
|
||
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".
In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body contains places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.
Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.
Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in
before you can comment on or make changes to this bug.
Description
•