Cannot move (drag, copy, or cut) live bookmarks that have no site location

RESOLVED FIXED

Status

()

Firefox
Bookmarks & History
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: protejohnny, Unassigned)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008052106 Minefield/3.0pre

Some RSS feeds have no home page link. When creating a live bookmark from such a feed, the "Site Location" field is left blank. For whatever reason, this prevents you from moving live bookmarks around Firefox, via drag and drop, copy, or cut and paste. None of these actions work with location-less live bookmarks on the bookmarks toolbar, in the bookmarks menu, or in the library.

There's an easy workaround for this. If you specify any "Site Location"--even a dummy one like "about:blank"--then you're able to move the live bookmark as expected.

Reproducible: Always

Steps to Reproduce:
1. Create a live bookmark with no site location (on the bookmarks toolbar, in a menu, in the library... it doesn't matter where)
2. Try to drag, copy, or cut it
3.
Actual Results:  
Nothing happens. You can't "pick it up" if you try to drag. If you attempt to copy or cut it, this exception is thrown:

self.livemarks.getSiteURI(bNode.itemId) is null
Line 473 of modules/utils.js

Nothing is put in the clipboard and nothing is available to paste.

Expected Results:  
You should be able to move it as you would a normal bookmark or live bookmark.

Here's a sample RSS feed that has no home page link. You can create a live bookmark from it to see the problem.
http://projects.protej.com/testfeeds/noloc/feed.html
(In reply to comment #0)
> You can create a live
> bookmark from it to see the problem.

Not really, no: thanks to bug 364677, that doesn't give a feed preview, and thanks to (dunno if anyone filed it) there's no menu item in the organizer anymore to create a livemark, so short of adding it in 2.x and importing the profile, you can create a livemark from data:text/html,<link rel="feed" href="http://projects.protej.com/testfeeds/noloc/feed.html"> and then clear the bogus site location from the livemark properties, and then, yeah, it fails as you say.
Severity: minor → normal
Status: UNCONFIRMED → NEW
Component: Bookmarks → Places
Ever confirmed: true
Keywords: regression
OS: Windows Vista → All
QA Contact: bookmarks → places
Hardware: PC → All
Version: unspecified → Trunk
(Reporter)

Comment 2

9 years ago
Indeed you're correct, Phil. When you create a live bookmark from a feed without the link channel, it automatically sets the "Site Location" to about:blank. It didn't even occur to me that it was a problem with imported feeds, which my test feed originally was.

I suppose this bug ought to read, "you can clear the Site Location and *then* encounter the problems attempting to drag, copy, or cut the livemark." It's still a problem that exists only with live bookmarks that have no link. In all other cases, Firefox determines the siteURI directly from the feed, regardless of attempts by the user to change/clear it in the bookmark's properties. (Related question: if this is the intended behavior, shouldn't the "Site Location" field be read only in the properties dialog and library?)
I don't think it should be read only, though there's no real good UI to say "here, you can change this, but I can't predict whether or when I might overwrite your changes" - I think my change to always update to what's in the feed in bug 341972 was the right thing to do more often than not, but I have to admit I didn't really think about intentionally changing (because the link in the feed is bogus? just to have it go somewhere else?) and having your intentional change overwritten.

I also haven't seen about:blank as a siteURI - can you give exact, painfully detailed steps to get to that? If we imported about:blank from a previous version having set it, that's too bad, but if you set it to something different, and then reloading the feed and finding no link "updates" an existing siteURI to about:blank, that's a bug.
(Reporter)

Comment 4

9 years ago
No, I agree with that change--getting the link from the feed is the right thing to do. Although, there were times (in Fx2's day) when I changed the siteURI to something that made more sense. For example, I used to subscribe to a newspaper columnist's feed, but wanted the "Open Location" to point to that columnist's archives rather than the newspaper's home page, which was the feed's default link. This is something I can totally live without, but a user might attempt to change the Site Location with a similar tweak in mind.

To be clear, Fx3 does NOT replace a valid siteURI with about:blank (or any other incorrect URL). But here's how I ended up with about:blank as my live bookmark's location...

1) In Firefox's Options dialog, on the Applications prefpane, set the "Web Feed" action to "Add Live Bookmarks in Firefox." 
2) Focus on a blank tab or go to the about:blank location.
3) Open the location of a link-less feed (e.g. http://projects.protej.com/testfeeds/noloc/feed.html).
4) The "Add Live Bookmark" dialog should pop up. Go ahead and save the livemark to wherever.
5) Check the new live bookmark's properties and the Site Location will be about:blank.

After some basic tests, it turns out that whatever page you're on in step 3 becomes the live bookmark's siteURI. That makes sense, but may not always be correct. You can change/clear the Site Location and Firefox will remember the manually-specified siteURI, even after subsequent live bookmark updates. This works exactly as expected.
Error: An error occurred executing the cmd_cut command: [Exception... "'[JavaScript Error: "self.livemarks.getSiteURI(bNode.itemId) is null" {file: "file:///C:/mozilla-central/obj-i686-pc-mingw32/browser/dist/bin/modules/utils.js" line: 543}]' when calling method: [nsIController::doCommand]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: chrome://global/content/globalOverlay.js :: goDoCommand :: line 87"  data: yes]
Source File: chrome://global/content/globalOverlay.js
Line: 91
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
should have been fixed along with bug 663269
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Depends on: 663269
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.