Closed Bug 347212 Opened 19 years ago Closed 17 years ago

[10.4] Dragging a URL from the Location bar causes duplicate drop

Categories

(Camino Graveyard :: Drag & Drop, defect)

Product:
Camino Graveyard
Component:
Drag & Drop
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mak, Unassigned)

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20060802 Camino/1.2+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20060802 Camino/1.2+ In recent nightly builds I am seeing the same behavior documented in bug 223315. But see comment 73 in that bug--it is claimed to be due to a bug in 10.3.x that was fixed in 10.4.x. However I am running 10.4.7 and am seeing the duplicate bookmarks after dragging a URL from the location field to the bookmark bar, a folder within the bookmark bar, or to any location on the bookmark page. Reproducible: Always Steps to Reproduce: Drag favicon/icon in location field to bookmark bar, folder in bookmark bar, or any place with bookmarks page open. Actual Results: Two bookmarks are created at the dragged location. Expected Results: Only one bookmark should have been created. See bug 223315 http://bugzilla.mozilla.org/show_bug.cgi?id=223315
Keywords: regression
When I drag a bookmark into the bookmark bar on trunk I do not get this behaviour.
The title of this bug says it "can randomly" happen, but your description says it's always reproducible. Which is it? Does this create a variable number of bookmarks (repeatedly until the cursor moved out of the drop area, IIRC), or is it always two?
Summary: [10.4] Dragging a URL from the Location bar can randomly create multiple bookmarks copies → [10.4] Dragging a URL from the Location bar creates duplicate bookmarks
Sorry, I had copied this title from the other bug (223315). I fixed it to be more accurate.
It always creates 2 bookmarks. I was wrong about one thing--when you have another browser window open to the bookmarks page, and you drag a URL into the list, only one bookmark is created. The duplicate problem apparently is limited to dragging into the Bookmarks Bar or into a folder in the Bookmarks Bar.
This is starting to sound like a different bug. Mark, do you see the drag image (the image/text that you move around when you drag the URL) jump around buggily when it happens? And can you make multiple .webloc files in the Finder by dragging the URL there? If so, it's more like the Panther bug; if not, it may be a coincidence.
There is something buggy about the drag from the location bar, but perhaps not the same as the previous bug. The drag cursor doesn't jump around, but while dragging, the drag string (favicon + title of the web page) gets overlayed in the location bar and doesn't get erased until the drag completes (ie. the drop). You can even see this if you just drag the favicon to the right a little bit. If you let go without dragging anywhere there will be two animations of the drag string moving to the left and then it clears. No duplicates are created when dragging to the desktop or to a finder window.
Can you regress this to the specific build where the behavior started?
OK I regressed this through previous nightly builds. The first nightly trunk build where I could reproduce this was: 2006072501.
That gives http://tinyurl.com/gqnk8 It's possible that the fix for bug 338694 could have done something. Still, shouldn't everyone be seeing this?
Can you repro this with a clean bookmarks.plist file? cl
I created a new user id on my Mac and tried it. I still get the behavior. One thing I noticed was that it didn't happen on the default Camino home page. However it does create two bookmarks in the bookmarks bar using the URL http://www.yahoo.com. So I'm the only one that can reproduce this?
I was able to repro *once* on Yahoo's home page, but I have not yet been able to reproduce it a second time, nor have I been able to reproduce it on any other page besides Yahoo's home page. cl
It also happens on this bug page -- https://bugzilla.mozilla.org/show_bug.cgi?id=347212 Also http://www.google.com Sometimes there is a several second pause before the second item in the bookmarks bar appears.
There's definitely something funky going on with dragging here, because on Google's home page, with multiple tabs/windows open, I can (again, not every time, but I was able to repro more than once, and now I can't) trigger a condition where the favicon and page title duplicate themselves while the drag is live, almost like I've accidentally picked up my finger off the trackpad in the middle of a drag or something. When I terminate the drag, both translucent drag objects get passed through to the drag target, resulting in two bookmarks on the Bookmarks Bar. This behaviour is *not* confined to the bookmarks bar, either. If I do the same thing with the favicon in the location bar and drop it on the empty area of the tab bar, I can get two tabs opened with the same URL. (The drop has to occur far enough over in the empty area that the next new tab would not be created under the cursor. If this is the case, you get a double-load of the URL in the newly created tab.) As for why it doesn't occur on every page, I suspect there's an interaction with the text cursor in the page. Every instance where I was able to reproduce this had a text cursor blinking in a form field somewhere in the page. (In that respect, this bug is somewhat reminiscent of our formerly awful typing performance in the presence of animated GIFs.) cl
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [10.4] Dragging a URL from the Location bar creates duplicate bookmarks → [10.4] Dragging a URL from the Location bar causes duplicate drop
By the way, this happens whether I use the trackpad or external mouse, so I don't think there are any weird trackpad issues here. cl
(In reply to comment #14) [description of experience] Are you sure you're not running Panther? That sounds exactly like my experience with bug 223315, and according to Smokey (bug 223315 comment 73) it's an OS bug that should be gone in 10.4. If you're seeing this too, something is definitely up.
(In reply to comment #16) > (In reply to comment #14) > [description of experience] > > Are you sure you're not running Panther? Yes. Very very sure. :) cl
Is this only on the trunk, or can people repro on the branch, too? If it's on the branch, too, does the branch have the same regression date?
Version: unspecified → Trunk
Chris, can you do the legwork on this, since you're seeing it? Mark's moved on to 10.5 and couldn't get branch builds to launch at all.... If it's trunk-only, it could be some Cocoa widget change having ill effects for us.
I was finally able to try the branch--I could not reproduce the problem.
Just wanted to chime in that I'm seeing this same behavior consistently on my Intel trunk builds. 10.4.7 of course.
Josh said he's pretty sure Cocoa drag-drop (bug 332913) will fix this.
Component: Bookmarks → Drag & Drop
QA Contact: bookmarks → drag.drop
Seeing the same behaviour in 10.4.8, also insertion caret pointer doesn't appear at the insertion point and the dragged URL sometimes separates from the cursor making it difficult to accurately drop something to the bookmark toolbar.
Are people still seeing this on current *trunk* nightlies? Cocoa drag-drop landed a while ago and should have fixed this....
(In reply to comment #24) > Are people still seeing this on current *trunk* nightlies? Cocoa drag-drop > landed a while ago and should have fixed this.... > Yes, but I have to drag _slowly_, and even then, it doesn't always happen.
Confirming on a fresh build.
(In reply to comment #24) > Are people still seeing this on current *trunk* nightlies? Cocoa drag-drop > landed a while ago and should have fixed this.... > I just updated to 2007032611 and it didn't do it if you do the dragging slow, but if you do it quickly it does do it. I made a quick video to help you guys see this, the first 3 times it doesn't do it, but the forth it does (after you speed up the dragging) and you have 5 bookmarks of the page rather than 4. http://homepage.mac.com/jmujica/camino/bug347212.mov
Confirming on 1.5rc. I'm not sure if it's completely consistent, but it's happening every time during this session, at least, unlike comment 27. Also, unlike in Jonathan's video, I'm actually getting a second drag image. It shows up after a short period during the drag and doesn't follow the mouse. If I drop the bookmark over the menu bar, I see two "snap-back" animations, one after the other. If I had to guess, I'd say we're actually performing two drags at once. http://other.peeja.com/doubled-drag.mov (Forgive the green watermark overlay; I'm using a demo of IShowU.)
Huh. Restarted Camino, and it was still there. Fresh profile, still there. Upgraded to RC2, now it's gone. It's possible the changes between RC1 and RC2 fixed it, but more likely it's lying in wait again. Those more familiar with the changes between the versions would know better.
I wonder if bug 345425 caused this? The ranges are very close, but just outside each other based on the info here. If that's the case, it could be (possibly) fixed on branch by bug 370721 but still extant on trunk.
Same problem is on Camino 2.0 alpha. Version 2007071201 (2.0a1pre) Always dragging URL to bookmark bar cause two entries.
Rick, would you mind testing a branch build for a while and seeing if the duplicates happen there (i.e., test my theory in comment 30)?
I tested this on today's nightly branch build (2007083002 (1.6a1pre)), and there are no duplicates. However the duplicates still happen on the nightly trunk build.
If this is trunk only, then this sounds an awful lot like a dup of bug 354371 (I know this was filed earlier, but since there's analysis there it should be duped that way).
Has anyone been able to reproduce recently (on Camino trunk) ? I tried multiple times but no duplication anymore. Possibly fixed for the same reason bug 354371 got fixed ?
I can't reproduce this in latest trunk build on 10.4. This seems to be fixed.
Possibly this is a dupe of bug 354371, but since so much time has passed, let's resolve WFM.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.