If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

dragging proxy icon does not drag title

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
Bookmarks & History
P2
normal
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: Cyril Bortolato, Assigned: Alec Flett)

Tracking

({helpwanted})

Trunk
mozilla1.0
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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

Comment 1

18 years ago
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

Updated

18 years ago
Keywords: nsbeta2
Target Milestone: --- → M17

Comment 2

18 years ago
Putting on [nsbeta2+] radar for beta2 fix.   claudius, can we get a retest.  
Thanks!
Whiteboard: [nsbeta2+]

Comment 3

18 years ago
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

Comment 4

18 years ago
Move to M18 target milestone.
Target Milestone: M17 → M18

Comment 5

18 years ago
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. ***

Comment 7

18 years ago
*** Bug 38361 has been marked as a duplicate of this bug. ***

Comment 8

18 years ago
removing nsbeta2+ for reconsideration.  This is ugly, but not a beta stopper.
Nominating for beta3 consideration
Keywords: nsbeta2 → nsbeta3
Whiteboard: [nsbeta2+]

Comment 9

17 years ago
Putting on relnote2 radar.
Keywords: relnote2

Comment 10

17 years ago
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

Updated

17 years ago
Keywords: correctness
Whiteboard: [b3nav+]

Comment 11

17 years ago
nav triage team: [b3nav+] now = nsbeta3+
Whiteboard: [b3nav+] → [nsbeta3+]

Updated

17 years ago
Priority: P3 → P4

Comment 12

17 years ago
Per PDT meeting, downgrading to beta3-minus
Whiteboard: [nsbeta3+] → [nsbeta3-][minus]
(Reporter)

Comment 13

17 years ago
*** 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

Comment 16

17 years ago
*** Bug 58886 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
*** Bug 58579 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 18

17 years ago
*** Bug 60353 has been marked as a duplicate of this bug. ***

Comment 19

17 years ago
*** 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]

Comment 21

17 years ago
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
(Assignee)

Comment 24

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 25

17 years ago
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

Comment 26

17 years ago
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
(Assignee)

Comment 27

17 years ago
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.

Comment 28

17 years ago
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
(Assignee)

Comment 29

17 years ago
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?

Comment 30

17 years ago
> 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.

Comment 31

17 years ago
> 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.
(Assignee)

Comment 32

17 years ago
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

Comment 33

17 years ago
*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.*
(Assignee)

Comment 34

17 years ago
*** Bug 66433 has been marked as a duplicate of this bug. ***

Comment 35

17 years ago
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.

Comment 36

17 years ago
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

Updated

17 years ago
Keywords: 4xp

Comment 37

17 years ago
*** Bug 66717 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 38

17 years ago
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

Comment 39

17 years ago
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.

Comment 41

17 years ago
It works for me on 2001030110, too. Some other fix must have fixed this, too.
Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 42

17 years ago
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.

Comment 43

17 years ago
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.