The default bug view has changed. See this FAQ.

Dragging bookmark from Safari to Camino removes bookmark rather than copies

RESOLVED FIXED in Camino1.5

Status

Camino Graveyard
Bookmarks
P2
normal
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Assigned: froodian (Ian Leue))

Tracking

({fixed1.8.1.1, regression})

unspecified
Camino1.5
PowerPC
Mac OS X
fixed1.8.1.1, regression
Bug Flags:
camino1.0 -

Details

Attachments

(1 attachment, 2 obsolete attachments)

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

12 years ago
Need to use the copy dragging mask for non-local drags.
Flags: camino1.0+
Priority: -- → P2
Target Milestone: --- → Camino1.0
but these aren't drags we originate. do those flags still matter on the drop site?

Comment 3

12 years ago
I think it can, if the source implements draggedImage:endedAt:operation: .

Comment 4

12 years ago
Oh, hrm, misread. Yeah, I'm not sure if we can affect what Safari is doing.

Comment 5

12 years ago
Created attachment 200830 [details] [diff] [review]
Forces a call to NSDragOperationCopy if the dropped data is not Camino Bookmarks
Assignee: mikepinkerton → nick.kreeger
Status: NEW → ASSIGNED

Comment 6

12 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

12 years ago
Created attachment 200837 [details] [diff] [review]
Possible alternative patch

Comment 8

12 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 on attachment 200837 [details] [diff] [review]
Possible alternative patch

sr=pink 

looks good.
Attachment #200837 - Flags: superreview+
Assignee: nick.kreeger → sfraser_bugs
Status: ASSIGNED → NEW

Comment 10

12 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
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

11 years ago
Pushing off the 1.0 list.
Flags: camino1.0+ → camino1.0-
Target Milestone: Camino1.0 → Camino1.1
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

11 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

11 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

11 years ago
Created attachment 247335 [details] [diff] [review]
Forces drag to NSDragOperationCopy if the dropped data is from an external app
Assignee: nobody → stridey
Status: NEW → ASSIGNED
Attachment #247335 - Flags: review?(stuart.morgan)

Comment 17

10 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

10 years ago
Attachment #247335 - Flags: superreview?(mikepinkerton)
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

10 years ago
Attachment #200837 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Attachment #200830 - Attachment is obsolete: true
(Assignee)

Comment 19

10 years ago
Checked in on 1.8branch and trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Keywords: fixed1.8.1.1
You need to log in before you can comment on or make changes to this bug.