227024 - bookmark name not based on <title> when dragging the URL from the URL bar

Status: RESOLVED WORKSFORME

(Firefox :: Bookmarks & History, defect)

Description

[riscky]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031120 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031120 Firebird/0.7+

It seems if you open a few links in tabs then modify the URL (removing the
anchor tag link) then drag the URL into to the bookmarks toolbar folder the page
name from <title> is used to form the pages name.

Reproducible: Always

Steps to Reproduce:
1.load http://www.macosxhints.com/article.php?story=20031116102201978#comments
in a tab
2. edit the URL and remove #comments (hit return)
3. drag the new url to the Bookmarks Toolbar

Actual Results:  
Bookmark is called article.php

Expected Results:  
Bookmark should be called macosxhints - 10.3: Play Chess in a floating desktop
window as would be the case if dragged the first URL (the one with an anchor) to
the Toolbar.

Comment 1

[Mike Connor [:mconnor]]

INVALID -> intended behaviour

reasoning is that once the URL is modified, it is not the same link and 
therefore should not be named based on the title of the currently displayed 
page.  if you delete, hit enter, then drag/Ctrl-D, it works as you wish, 
because the title attribute is linked to the current URL.  Doing a check 
whether the link is the same without the anchors solely for URIs with anchors 
is a little too much of an edge case to do it for every add bookmark function.

If you removed the l from an .html link, it is not the same file and does not 
necessarily have the same link.

Comment 2

[riscky]

Of course when you remove part of the url and don't press return it's not the
same link... when you do press return, the page default read starts at the
top... so the load of the modified URL was made... then dragging THAT url just
shows up as article.php and not the intened name... which is the whole point...

I am not saying chopping off part of a URL then bookmarking that should have the
same name, based on title, or the orginal URL. But when you modifidy the URL
then press enter the name, from the title, should stick.

Comment 3

[riscky]

I must reopen this... because if it doesn't work as intended.

My reson being is if open the link below (in a new window) modify the url press
enter (thus a different loded link) and drag it the the Bookmark tool bar name
is article.php. If I then create a new tab then add the URL I get the name based
on <title>.

Comment 4

[Mike Connor [:mconnor]]

In that case, Works for me using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.6b) Gecko/20031128 Firebird/0.7+

Comment 5

[Ali Ebrahim]

I'm going to confirm this bug because I can confirm what the reporter is seeing
on Windows and Linux. It's somewhat of a grey area, but I think that the bug is
valid. When moving between the same document but between anchors the page icon
to the left of the URL is not draggable, and only the URL itself is draggable.
Under these circumstances, when the URL icon is not draggable (because you've
just moved from one anchor to another), you MUST select the URL itself and drag
that. This causes the wrong behaviour to occur, ala the "Bookmark is called
article.php" that the reporter sees.

Confirming on Windows/Linux 2003-11-28. I would say that this is a bug, though
to be honest I'm not sure if its a bookmarks bug or a toolbars bug, and someone
definitely needs to update the summary of the bug, but I'm at a loss for words
to describe this in a succint manner.

mconnor, can you triage this further? This problem really is hard to describe
and you only really get a feel for it if you play around with it.

Alternate steps to reproduce:
1. Enter http://bugzilla.mozilla.org/show_bug.cgi?id=227024#c1 in the URL bar
2. Hit enter
3. Enter http://bugzilla.mozilla.org/show_bug.cgi?id=227024#c2 in the URL bar
4. Hit enter
5. Try dragging the page icon to the left of the URL (doesn't work)
6. Select the URL and drag that instead (makes a bookmark called show_bug.cgi).

This is the wrong behaviour. I consider this to be a bug because if you skip
steps 3 and 4 then both steps 5 and 6 create a bookmark with the CORRECT name
based on <title>.

Comment 6

[Ali Ebrahim]

There is an analgous behaviour on Win32 that seems to be strongly related:

1. Go to http://bugzilla.mozilla.org/show_bug.cgi?id=208314#c35
2. drag page icon to BTF
3. right click on new bookmark in BTF and delete it
4. go back to URL bar without clicking anywhere else.
5. try typing something. nothing happens

Comment 7

[Ali Ebrahim]

Moved over to Toolbars as per conversation with mconnor.

Comment 8

[Brian Salomaki]

While this bug itself is quite old, it seems related to a Camino bug that I can't find any closer equivalent to:
https://bugzilla.mozilla.org/show_bug.cgi?id=320410

The proposed solution of popping up a rename dialog every time a URL is dragged to the toolbar (perhaps with a pref to toggle behavior) would potentially make this bug a non-issue.

Comment 9

[Mardeg]

Confirming an easier way to reproduce:

1. Go to Enter http://bugzilla.mozilla.org/show_bug.cgi?id=227024
2. Click any anchor link (ie. Comment #2)
3. Drag the tab to the Bookmarks Toolbar. (Edit: just dragging the same anchor link you navigated to onto the toolbar shows this bug too) 

show_bug.cgi appearing as the bookmark name requires that you first navigate within a page to an anchor (or alter the address bar as stated in above comments).

Aside: When dragging any anchor link to the bookmarks toolbar (other than the one you are currently on that produces this bug) only the anchor's name is used. Yet when dragging the tab of a url with an anchor (opened in a new tab so as not to reproduce this bug) only the page title is used. This seems inconsistant behaviour that would be resolved by using the page title with the anchor name appended to the end in both cases. Should this be filed as a new bug, or dealt with in this one?

Comment 10

[:Gavin Sharp [email: [e-mail]]]

I can't reproduce the steps in comment 5 or comment 9 anymore. I do see the bookmark name differing if you drag the URL text rather than the favicon to the bookmarks bar, though. I suppose we could compare text drops to the currentURI, and use the current title if they match?

Comment 11

[dangelo.rj]

It is happening right now in macOS Firefox Developer 54.0a2 (2017-03-29) (64-bit): Dragging the site information icon (i) to a folder creates a .webloc file named after the URL rather than the <title>

Comment 12

[Frank Griswold [:griswolf] [:fgriswold]]

It is happening right now in MacOS Firefox Release 53.0, though in a slightly different context: My issue is that dragging the url to the MacOS Finder gives the same result: The name of the file in the Finder window is based on the url rather than being based on the title. I first noticed this with release of 53.0, though it is possible that it was the release prior, so this is a regression.
Steps to duplicate:
Visit any page. Note the <title>
Drag the url to a finder window
Note that the name of the file in that window is based on the url, not the title.

Comment 13

[Frank Griswold [:griswolf] [:fgriswold]]

Attachment: Shows the webloc file based on the url for this bug

Comment 14

[Martin Campbell]

I see exactly the same behaviour as dangelo and griswolf.
Using macOS Sierra 10.12.4 and Mozilla Firefox 53.0.
Visit any web site.
Drag icon to left of URL in address bar to Finder.
Webloc file is created with URL as file name instead of title.

Comment 15

[Giordano]

The same happens to me. Starting from Firefox version 53, dragging the icon near the site address results in a file with URL as file name instead of page title.  

macOS Sierra 10.12.4
Here is the example image (Firefox 52 vs Firefox 53)
https://pbs.twimg.com/media/C-cNzN5XYAAjJwZ.jpg

Comment 16

[Nathan]

I upgraded to Firefox 53 from Firefox 52 and I see the same bug described above in comment 12, comment 14, and comment 15, and I am on an earlier version of macOS, namely Mavericks 10.9.5. Dragging the "site information" icon from the address bar to a Finder window creates a .webloc file with URL as filename instead of page title (whereas page title as filename was the prior, and preferred, behavior).

Comment 17

[Nathan]

I upgraded to Firefox 54.0.1, and the behavior reported in the preceding five comments is fixed: Dragging the "site information" icon from the address bar to a Finder window creates a .webloc file with page title as filename, as desired. Tested in Mavericks 10.9.5.

Comment 18

[Frank Griswold [:griswolf] [:fgriswold]]

Also noted that the regression was fixed. Is there a (unit) test for this issue? 'Twould be a shame if it recurred again later

Comment 19

[u601040]

This works as expected for creating a webloc in finder, but if you drag directly into text editor or email it shows a link in a pre-defined font with the url instead of the title of the page on OS X 10.11.6.

Whats happening: URL as text with preset font

Expected behavior: Match text style and insert link with page title as text

Comment 20

[Frank Griswold [:griswolf] [:fgriswold]]

A webloc has two distinct elements: The title and the url. This makes it easily feasible to do the right thing by using the <title> for the webloc file name and the url for the link. I suspect that no matter where you drag the url-bar, the target is responsible for handling both parts of the data. Mac Finder does a good job. My email and LibreOffice do not.

Comment 21

[ffuser]

This works as expected with another popular browser that rhymes with 'dome' which leads me to believe source applications can provide 'hints' to the receiving application.

Comment 22

[Nathan]

I have used Firefox for Mac for over a decade, and for as long as I can remember, dragging the page URL or "site information" icon from the Firefox address bar to any plain-text OR rich-text editor has always only inserted the URL. As I remember, the page title has never been inserted as anchor text in a text editor window, in contrast to how the page title becomes the filename of a .webloc file when dragging from the Firefox address bar to the Finder. The mentioned "preset font" issue may be an issue with Apple's Cocoa text engine, since dragging to Microsoft Word and NeoOffice Writer (neither of which use Apple's Cocoa text engine) correctly matches the document's font at the insertion point. I don't know enough about Firefox internals to know how easy it would be to change the longstanding current behavior. However, there may also be a Firefox add-on that will give you the behavior that you desire. For example, I have not tested it, but the "Copy Urls Expert" add-on may have an option to copy a link in the format you desire: https://addons.mozilla.org/en-US/firefox/addon/copy-urls-expert/

(In reply to u601040 from comment #19)
> This works as expected for creating a webloc in finder, but if you drag
> directly into text editor or email it shows a link in a pre-defined font
> with the url instead of the title of the page on OS X 10.11.6.
> 
> Whats happening: URL as text with preset font
> 
> Expected behavior: Match text style and insert link with page title as text

Comment 23

[ffuser]

(In reply to Nathan from comment #22)
> dragging the page URL or "site information" icon from the Firefox

Thanks. grep'd code for 'site information' led me to "Identity" and then narrowing down to files containing "url", "title/name", "drag and drop" led me to the right section of code. A minor patch changes things to to my preferred behavior.

Comment 24

[ffuser]

same issue but with gifs!  https://github.com/brave/browser-laptop/issues/10956

Comment 25

[ffuser]

issue occurs here: 

<src>/widget/cocoa/nsDragService.mm 

and is fixed by using URLPasteboard instead of generic Pasteboard when dealing with site info dragging / URLs :

    [pboard declareURLPasteboardWithAdditionalTypes:@[ NSFilesPromisePboardType ]
    owner:nil];
    [pboard setDataForURL:url title:title];

    [pboard setPropertyList:@[ @"webloc" ] forType:NSFilesPromisePboardType];