Closed
Bug 313740
Opened 19 years ago
Closed 18 years ago
Dragging bookmark from Safari to Camino removes bookmark rather than copies
Categories
(Camino Graveyard :: Bookmarks, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
Camino1.5
People
(Reporter: alqahira, Assigned: froodian)
Details
(Keywords: fixed1.8.1.1, regression)
Attachments
(1 file, 2 obsolete files)
4.17 KB,
patch
|
moz
:
review+
mikepinkerton
:
superreview+
|
Details | Diff | Splinter Review |
Spun off from bug 313338 (reporter never filed a follow-up, but it seemed significant enough): "Also when transferring individual Bookmarks from Safari to the earlier Camino version the transfer was a copy leaving the original with Safari. Now the transfer is total eliminating the Bookmark from Safari." If you drag a bookmark from Safari's manager to Camino's manager, the bookmark is removed from Safari's manager. When we go the other way, we copy the bookmark into Safari and keep our original. In 0.8.4, it was a copy both ways (although moving a bookmark from Safari to Camino resulted in the bookmark's URL being used as its name). Any chance this regressed due to changing bookmarks to the shared pasteboard format or whatever?
Comment 1•19 years ago
|
||
Need to use the copy dragging mask for non-local drags.
Flags: camino1.0+
Priority: -- → P2
Target Milestone: --- → Camino1.0
Comment 2•19 years ago
|
||
but these aren't drags we originate. do those flags still matter on the drop site?
Comment 3•19 years ago
|
||
I think it can, if the source implements draggedImage:endedAt:operation: .
Comment 4•19 years ago
|
||
Oh, hrm, misread. Yeah, I'm not sure if we can affect what Safari is doing.
Comment 5•19 years ago
|
||
Assignee: mikepinkerton → nick.kreeger
Status: NEW → ASSIGNED
Comment 6•19 years ago
|
||
Comment on attachment 200830 [details] [diff] [review] Forces a call to NSDragOperationCopy if the dropped data is not Camino Bookmarks This doesn't fix the case of dragging into a root bookmark folder on the left.
Attachment #200830 -
Flags: review-
Comment 7•19 years ago
|
||
Comment 8•19 years ago
|
||
Comment on attachment 200837 [details] [diff] [review] Possible alternative patch This is a better alternative to my patch, looks good, tested and works just fine
Attachment #200837 -
Flags: review+
Comment 9•19 years ago
|
||
Comment on attachment 200837 [details] [diff] [review] Possible alternative patch sr=pink looks good.
Attachment #200837 -
Flags: superreview+
Updated•19 years ago
|
Assignee: nick.kreeger → sfraser_bugs
Status: ASSIGNED → NEW
Comment 10•19 years ago
|
||
I don't think I like this patch. It seems that we should be checking for more specific drag operations first, then falling back on NSDragOperationGeneric. It's really safari's problem that it's willing to do a "move" to another application.
Status: NEW → ASSIGNED
Comment 11•19 years ago
|
||
but how can we check other ones and fall back if the bug happens because we're doing just that? have we filed a bug with apple that safari is wrong? Doesn't help safari releases already in the field though. simon, what do you want to do here?
Comment 12•19 years ago
|
||
Pushing off the 1.0 list.
Flags: camino1.0+ → camino1.0-
Target Milestone: Camino1.0 → Camino1.1
Reporter | ||
Comment 13•18 years ago
|
||
How should we proceed to fix this on our end? It won't help with all the existing versions of Safari out there (esp. on 10.3.x), but could someone file a bug/talk to Safari team members and get them to fix the bug on their end for the future?
Assignee: sfraser_bugs → nobody
Status: ASSIGNED → NEW
QA Contact: bookmarks
Comment 14•18 years ago
|
||
I don't suppose there's any way to know where the drag target is if it's not internal to Camino, is there? If there is, couldn't we simply tell Safari "sorry, we're not moving bookmarks there"?
Comment 15•18 years ago
|
||
(In reply to comment #14) > I don't suppose there's any way to know where the drag target is if it's not > internal to Camino, is there? > > If there is, couldn't we simply tell Safari "sorry, we're not moving bookmarks > there"? Ignore the above; I was thinking this bug was backwards of what it really is. From IRC: [6:01pm] <Wevah> we should be able to check for dragSourceView == nil or something cos if it's nil, it's from another app If it's from another app, we should force a copy, rather than allowing the app to be stupid and move things to Camino. Right? cl
Assignee | ||
Comment 16•18 years ago
|
||
Comment 17•18 years ago
|
||
Comment on attachment 247335 [details] [diff] [review] Forces drag to NSDragOperationCopy if the dropped data is from an external app codewise r=me
Attachment #247335 -
Flags: review?(stuart.morgan) → review+
Assignee | ||
Updated•18 years ago
|
Attachment #247335 -
Flags: superreview?(mikepinkerton)
Comment 18•18 years ago
|
||
Comment on attachment 247335 [details] [diff] [review] Forces drag to NSDragOperationCopy if the dropped data is from an external app sr=pink
Attachment #247335 -
Flags: superreview?(mikepinkerton) → superreview+
Assignee | ||
Updated•18 years ago
|
Attachment #200837 -
Attachment is obsolete: true
Assignee | ||
Updated•18 years ago
|
Attachment #200830 -
Attachment is obsolete: true
Assignee | ||
Comment 19•18 years ago
|
||
Checked in on 1.8branch and trunk.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•18 years ago
|
Keywords: fixed1.8.1.1
You need to log in
before you can comment on or make changes to this bug.
Description
•