Closed Bug 29403 Opened 25 years ago Closed 24 years ago

dragging proxy icon does not drag title

Categories

(SeaMonkey :: Bookmarks & History, defect, P2)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: cyril_bortolato, Assigned: alecf)

References

Details

(Keywords: helpwanted)

Steps to reproduce: 1) launch mozilla and open the bookmarks window 2) drag-n-drop an URL (using the green sign at the left of the URL bar) into the bookmarks window 3) in the bookmarks window, the new bookmark has no title and no added date Expected results: New bookmark should have the page's title and the current date in the "added date" field. Platform: 2000-02-26-09 on Linux
Confirmed with the 2000-03-01-08-M15 nightly binary on WinNT Expected: same new entry as choosing "Add Bookmark" from the "Bookmarks" menu Actual: The "URL" and "Added On" columns are empty; the URL ends up in the "Name" column.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: URL dragged into bookmarks window has not title & no dates → URL dragged into bookmarks window has no title & no dates
Keywords: nsbeta2
Target Milestone: --- → M17
Putting on [nsbeta2+] radar for beta2 fix. claudius, can we get a retest. Thanks!
Whiteboard: [nsbeta2+]
this is badly broken. I crashed once on linux (bug 29403 cited in comments if you want to look) but typically on all three platforms with the 2000051210 builds the following happens: the url of the bookmark is dropped in the 'Name' column - and nothing else, the other columns are empty Moreover, looking at the properties yields a properties diaog with all empty fields. The dropped 'bookmark' is not even context menu aware. Right-clicking on it doesn't generate a context menu. It is as if the bookmark di not exist. The 200050909 mac build executed this brightly, brightly and with beauty so maybe this was fixed and is a recent regression.
OS: Linux → All
Hardware: PC → All
Move to M18 target milestone.
Target Milestone: M17 → M18
Ben now gets most (if not all) of the drag and drop bugs.
Assignee: slamm → ben
*** Bug 38361 has been marked as a duplicate of this bug. ***
*** Bug 38361 has been marked as a duplicate of this bug. ***
removing nsbeta2+ for reconsideration. This is ugly, but not a beta stopper. Nominating for beta3 consideration
Keywords: nsbeta2 → nsbeta3
Whiteboard: [nsbeta2+]
Putting on relnote2 radar.
Keywords: relnote2
Updating summary per bug 38361.
Summary: URL dragged into bookmarks window has no title & no dates → URL dragged into bookmarks window has no title, date, or context menu
Keywords: correctness
Whiteboard: [b3nav+]
nav triage team: [b3nav+] now = nsbeta3+
Whiteboard: [b3nav+] → [nsbeta3+]
Priority: P3 → P4
Per PDT meeting, downgrading to beta3-minus
Whiteboard: [nsbeta3+] → [nsbeta3-][minus]
*** Bug 53629 has been marked as a duplicate of this bug. ***
now there is a context menu and a title (thank goodness), but it's the url. We should try and be a little smarter and attempt to sniff an appropriate title. Updating summary, targeting 1.0/6.5
Status: NEW → ASSIGNED
Summary: URL dragged into bookmarks window has no title, date, or context menu → URL dragged into bookmarks window has url as title
Target Milestone: M18 → mozilla1.0
This seems a little trivial to bother relnoting, so: It seems unclear to me whether this bug requires either of a "developer" or "user" release note for Netscape 6 RTM. If anyone feels it does, can they please draft one and then nominate with the relnote-user or relnote-devel strings in the Status Whiteboard. Thanks :-) Gerv
*** Bug 58886 has been marked as a duplicate of this bug. ***
*** Bug 58579 has been marked as a duplicate of this bug. ***
*** Bug 60353 has been marked as a duplicate of this bug. ***
*** Bug 62192 has been marked as a duplicate of this bug. ***
clearing keyword/status whiteboard cruft, nominating for nsbeta1.
Keywords: nsbeta3, relnote2 → nsbeta1
Whiteboard: [nsbeta3-][minus]
this seems like something that must be fixed before any "normal" user be be expected to use mozilla. Suggest to nominate for Keyword:mozilla0.9
Netscape Nav triage team: this is a Netscape beta stopper. reassigning to alecf
Assignee: ben → alecf
Status: ASSIGNED → NEW
Priority: P4 → P2
upgrading to mozilla0.9.
Target Milestone: mozilla1.0 → mozilla0.9
can someone see if this is still happening? this is a pretty old bug, and much of the drag 'n drop code has been updated since then. Note that there already is a bug that the SECOND time you drag a link, it drags just the title, not the url. this is bug 58122.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
YES, this bug is definetely still there! And YES, it is a very old bug indeed :-( Links dragged to the bookmarks in the sidebar or the bookmarks window only show the url and no the name. (moz build 20010123) This is something that needs to be fixed before normal users can be expected to use mozilla -> Keywords: helpwanted, mostfreq
according to this we have 7 dupes, it's shy of the original standard, but i'll bite. plairo: mozilla is not intended for normal users, so please don't waste bugzilla's space fighting for them. It is enough to say that it still doesn't work. I'll reopen after i get a verification build if no one else does so sooner.
Keywords: helpwanted, mostfreq
just to reconfirm, this is working fine for me... I can drag a link from the browser into the bookmarks window, and it works fine - url ends up the in the right place, the link text is the title of the bookmark, and so forth.
Let me reconfirm that it does not work for me in win2k (today's build), nor on a fresh install to a win2k laptop, nor to a fresh install on win nt 4+sp6a. Now what? ;-) Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010124
please be more specific about what "it" is that works. Are you dragging the proxy icon? Are you dragging a url from the desktop? are you dragging a url from somewhere else in the product? I just noticed that the summary of this bug does not match the original description.. the summary says that the dropped bookmark "..has url as title".. but the initial description says ".. has no title and no added date" which is it?
> url ends up the in the right place, the > link text is the title of the bookmark, and so forth. ^^^^^^^^^ I think this is the whole point of confusion. If you drag any LINK from a page to the bookmarks window, it is true that the text of that link is preserved. However, if you want to add the current page, by dragging the bookmark icon from the URL/Location bar, that's when you end up with the actual url in the bookmarks window, instead of the page's Title.
> However, if you want to add the current page, by dragging the bookmark icon > from the URL/Location bar, that's when you end up with the actual url in the > bookmarks window, instead of the page's Title. Well...the problem here is that that proxy icon contains the url in the url bar, not the url of the currently loaded page. So we don't know the title of the page if the user has changed the urlbar (although this admittedly wouldn't happen often), and I don't think it makes sense to contact the site and get it. We could use the title if the url matches the currently loaded page and the url if not, but that's inconsistent.
ah! ok, reopening and updating summary. I thought there was a dupe of this, maybe not
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: URL dragged into bookmarks window has url as title → dragging proxy icon does not drag title
*It*: drag from the url icon (just left of the URL in the location bar) to either the Manage Bookmarks window *or* to the bookmarks sidebar. In both cases the page URL winds up in the bookmark URL, but the bookmark title is *also* the URL, rather than the page's title as one would want. Aleka's close reading of the earlier text may resolve all issues. Heck, I didn't even know that you could drag from a *link* on a page to the bookmark management mechanisms... In all cases I refer to a scenario where the URL is that *of the currently loaded page.*
*** Bug 66433 has been marked as a duplicate of this bug. ***
Just to add a few more thoughts on blake's comments... By dragging the proxy icon in NS4.xx, you always end up with the page's title & URL, regardless of the contents of the url bar. This seems a lot more reasonable to me. Although I have absolutely no idea how this thing is currently implemented in Mozilla, some of my experiences are a little bit contradicting blake's description: 1. Every 1000 times (-well, sort of...) I drag a the proxy icon to the bookmarks window, the page's title gets stored _correctly_! I've only seen this happening 2 or 3 times within the last 30 days or so, but (-as you might have guessed) I cannot reproduce it. 2. If you run NS4.76 and Mozilla 20010124 on Win2K\SP1, and drag the proxy icon from NS4.76 to the Mozilla bookmarks window (-I've been doing this kind of stuff lately!), the entry _still_ won't have the page's title, but will show the URL instead! Point (1) may mean 2 things. Either the proxy always carries the title information but the bookmarks window rarely is able to extract it, OR, the bookmarks window works fine and it's just the proxy icon that rarely carries this information. Oh well, this whole thing doesn't seem to be very sound since I can't reproduce it... Point (2) tells me that the bookmarks window in mozilla is likely to be responsible for not being able to extract the title. That's because we know as a fact that the NS4.76 proxy does carry the title. An interesting thing is, if you drag the mozilla proxy icon to the Windows Desktop area, a 'shortcut' is created that _also_ bears no title! Hmmm... Anyway, there's a big chance that I'm missing something important here. As I said, I have no idea how this thing is actually coded. I just based those ideas on blake's description.
Actually this error also occurs in the *sidebar*, which is likely to be more used by users and therefore more relevant. The disappearance of the title, no matter where it is dragged to seems to indicate that it is the *proxy icon* (what a un-intuitive name) that is not retaining the page title info. I agree with Aleka that the currently *loaded* page's title should be copied, regardless of what is displayed in the url
Keywords: 4xp
*** Bug 66717 has been marked as a duplicate of this bug. ***
moving a few 0.9 bugs out to 1.0 to lighten my 0.9 load.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9 → mozilla1.0
Although I've seen this behavior often in the past I should note that with current builds I'm not seeing it. By it I mean dragging the proxy icon from the urlbar to the manage bookmarks window and dropping it there results in the creation of a well-formed new bookmark.
This is now working for me with the 2001021008 build and has been for the last couple of nightly builds.
It works for me on 2001030110, too. Some other fix must have fixed this, too. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
This has been working for me for right around a month. I vaguely remember there was a big bookmark window checkin right around the time this began to work. I also note that it doesn't seem to work in NS6.01, if that's a clue and if it matters.
VERIFIED Fixed 2001041004 builds
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.