149022 - Dragging proxy icon onto bookmarks icon causes bookmark to diappear.

Status: RESOLVED WORKSFORME

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Jon Levell]

Although bug #96504 has been fixed, and bug #148996 has been created to
re-enable the feature on the trunk, with the intermediate fix for 1.0, if I drag the
proxy icon onto the bookmarks button, the bookmark disappears, where-as it
should presumably be added to the bookmarks menu or (preferably) be left where
it is?

Comment 1

[Dave]

See also Bug 135983.  According to Pierre, it's fixed on the trunk by his fix 
for Bug 139471 (see Bug 135983 Comment 1, Bug 139471 Comment 41).  But maybe 
you want different behavior than what that fix provides (I don't even know what 
the behavior is, and I'm away from my computer)?  If you really want a bookmark 
dragged and dropped on the bookmarks button to "(preferably) be left where it 
is", then I'll do you one better:  there should be a crossed out circle 
(negative feedback, "you can't drop that here") for DnD bookmark or location 
bar proxy icons over the bookmarks button on the PT.  This is probably better 
than giving positive feedback then doing nothing, don't you think?

Comment 2

[Dave]

Definitely fixed on trunk (Win 98 nightly build 2002060108)

Comment 3

[Jon Levell]

I'm not sure that bug #135983 is relevant, I /think/ there are separate problems
in linux and Windows? (bug #96504 was a linux bug).

Comment 4

[Dave]

I see your point, but I see it works fine in Linux (nightly build 2002060308). 
So what you want is for this to work in in 1.0 also?

Comment 5

[Jon Levell]

I'd like it to work in the 1.0 branch e.g. 1.0.1 

Comment 6

[Kai Lahmann (is there, where MNG is)]

Jon: can you reproduce this with 1.1beta?

Comment 7

[Jon Levell]

No, it work's fine in the trunk and the new 1.1 branch I was originally hoping
it would be fixed in 1.0.1 and that branch to, that was the point of this bug
but I guess it's unlikely. Do you think I should resolve it "invalid"?

Comment 8

[Kai Lahmann (is there, where MNG is)]

if a problem has gone without knowing why it's WFM

Comment 9

[Jon Levell]

Kai: You don't seem to understand what I'm writing! This bug is not present in
the trunk or the 1.1 branch because bug #96504 has been fixed. I thought that
patch or a similar one should be checked into the long-lived stable 1.0.x branch
so that 1.0.1, 1.0.2 etc will not have this dataloss bug. The latest nightly 1.0
build (I just checked today) still displays this bug so the resolution of this
bug is *NOT* WFM. 

Comment 10

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 11

[Alexander Opitz]

closed as WFM ... cause 1.4 will be the new stable branch ... won't fixed in the
1.0 branch (the version flag should be change, if something should only repaired
in branch instead of trunk).