Closed
Bug 418088
Opened 17 years ago
Closed 16 years ago
drag & drop item from right pane to left pane does not automatically open target folder
Categories
(Firefox :: Bookmarks & History, defect, P2)
Firefox
Bookmarks & History
Tracking
()
VERIFIED
FIXED
Firefox 3 beta4
People
(Reporter: magicrisco, Assigned: asaf)
References
Details
(Keywords: regression, Whiteboard: [Fx2-parity])
Attachments
(1 file)
(deleted),
image/jpeg
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008021704 Minefield/3.0b4pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008021704 Minefield/3.0b4pre Drag and drop from right pane to left pane does not automatically open folder. Reproducible: Always Steps to Reproduce: 1.Open places 2.Drag and drop bookmark from right pane to left pane Actual Results: Folder does not automatically open Expected Results: Folder should automatically open
Keywords: useless-UI
Summary: Drag and drop from right pane to left pane does not open folder → Drag and drop from right pane to left pane does not automatically open folder
Comment 1•17 years ago
|
||
Seems to have occurred when the patch for bug 405198 was checked in. So probably related.
I have made [url=https://bugzilla.mozilla.org/show_bug.cgi?id=418084]bug 418084 - Folder animation inconsistent in places, folders stay open when navigating to new one[/url] which i feel is linked as well.
Assignee | ||
Updated•17 years ago
|
Comment 3•17 years ago
|
||
This works under OS X with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b4pre) Gecko/2008021704 Minefield/3.0b4pre ID:2008021704. Seems to be a Windows only issue. I'm not able to test under Linux.
Version: unspecified → Trunk
Assignee | ||
Comment 4•17 years ago
|
||
This is not implemented on mac either, assuming "should automatically open" means it should open _in the right pane_.
Comment 5•17 years ago
|
||
Mano, call it a wonder but under OS X the folder is opened in the left and the right pane!
Could this behaviour be related to Bug 337761 which is actually a Windows only Bug?
Comment 7•17 years ago
|
||
It is a regression from Firefox 2.
Flags: blocking-firefox3?
Keywords: regression
Assignee | ||
Comment 8•17 years ago
|
||
No, it's not implemented in Firefox 2 either
Flags: blocking-firefox3?
Keywords: regression
Assignee | ||
Updated•17 years ago
|
Summary: Drag and drop from right pane to left pane does not automatically open folder → Drag and drop from right pane to left pane does not automatically open folder in the right pane
Assignee | ||
Comment 9•17 years ago
|
||
(In reply to comment #5) > Mano, call it a wonder but under OS X the folder is opened in the left and the > right pane! > If I'm reading this bug right, it's about changing the _right_ pane contents when you drag over a non-selected folder in the left pane. This is implemented in neither Fx2-style bookmarks nor in Places (nor there is a code for that sort of functionality in nsTreeBodyFrame)
Comment 10•17 years ago
|
||
I'm clearly reading this wrong, here's what I understood as the bug: 1. bookmark menu 2. click and drag on random bookmark in the bookmark menu 3. drag over folder in bookmark menu In Firefox 3 (or the builds I've used recently), nothing then happens. In Firefox 2 the folder opens up, I know this to be true because I just tested it in Firefox 2.
Comment 11•17 years ago
|
||
Here you can see what I can't do in Firefox 3. I drag from the right to the left pane, the folder opens on dragover and shows/opens a sub folder.
Comment 12•17 years ago
|
||
Indeed. I agree with Ria. This is definitely a regression under Windows. D&D works perfectly in Firefox 2. Folders in the left and right pane opens automatically after a short time. Mano, and this is what comment 0 states. I'm still a bit confused about the updated summary. Why the right pane folder should open?
Keywords: regression
Comment 13•17 years ago
|
||
Uhh, not the bug I thought sorry, I'll do some more testing and see if I need to report some more bugs tomorrow.
Comment 14•17 years ago
|
||
re-adjusting bug title where 'target folder' could be either in left *and* right pane. works in: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 ID:2008020121 fails in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021704 Firefox/3.0.0.0 ID:2008021704 => regession + Fx2 parity + blocking-req is valid! btw. bookmarks sidebar is affected too -> file new bug?
Severity: enhancement → normal
Flags: blocking-firefox3?
OS: Windows Vista → All
Summary: Drag and drop from right pane to left pane does not automatically open folder in the right pane → drag & drop item from right pane to left pane does not automatically open taget folder
Whiteboard: [Fx2-parity]
Reporter | ||
Comment 15•17 years ago
|
||
Hi, just a bit of clarification for comment 12. The first issue, is that the folder is not opening after a hover state ( which it does in FF2 ), which you have of course you have seen. However, by the right pane opening, I meant that once I hover over the folder, it should open, then show that folders contents in the right hand pane. Would the second issue need a new bug?
Comment 16•17 years ago
|
||
Like Daniel and Damian said, it is the same / has the same cause as bug 337761 and will hopefully be fixed by this bug.
Blocks: nsIThreadManager
Depends on: 337761
Assignee | ||
Comment 17•17 years ago
|
||
yeah, that's the thread manager bug.
Updated•17 years ago
|
Summary: drag & drop item from right pane to left pane does not automatically open taget folder → drag & drop item from right pane to left pane does not automatically open target folder
Comment 18•17 years ago
|
||
Marking blocking, when bug 337761 is fixed, we can mark this one fixed, but this regression does need to be resolved before ship.
Flags: blocking-firefox3? → blocking-firefox3+
Updated•17 years ago
|
Assignee: nobody → mano
Priority: -- → P2
Reporter | ||
Comment 19•16 years ago
|
||
can anyone confirm this is fixed in the latest hourly? Bug 33761 has just been checked in. On my mobile so cant check myself.
Comment 20•16 years ago
|
||
Yes, this is fixed now.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 21•16 years ago
|
||
verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre and the same nightly on Win XP
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Hardware: PC → All
Comment 22•16 years ago
|
||
(This could have been a duplicate of bug 337761 or bug 338401.)
Comment 23•15 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
•