User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 I edit the properties of a live bookmark then click save. The properties are only saved until the next time the live bookmark is reloaded. After the live bookmark is reloaded it reverts back to the initial property information that was created when the live bookmark itself was created. Reproducible: Always Steps to Reproduce: 1.create live bookmark 2.right click live bookmark and go into properties 3.edit site location information and click save 4.right click live bookmark and click reload live bookmark 5.right click live bookmark and go into properties Actual Results: The changes made to the property of the live bookmark are no longer there. Expected Results: Expect the properties to be saved after the live bookmark reloads.

confirmed: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081106 Minefield/3.1b2pre There's no point in allowing edit site location if we're going to overwrite it on live bookmark loading

Actually, looks like we do this by design, we try to listen to livemark request and changes, still probably we should not allow to edit the site location to be consistent with that.

I noticed this today (nightly channel). Tried to edit the Feed Location field in a live bookmark and I couldn't get the changes to stick. In my case forcing a reload wasn't necessary to have the field go back to the original value (unless FF is doing that automatically). The way I worked around it was editing it in a Namoroka 3.6.20pre version and synching. Marco, I don't understand why it's overwritten, maybe a protocol requirement? Anyway, in my case, the bookmark pointed to an RSS feed whose location changed, so the refresh was always failing.

(In reply to jorge alves from comment #3) > Marco, I don't understand why it's overwritten, maybe a protocol > requirement? The service tries to respect the choice of the feed author, by updating its site uri (not sure if this is part of the protocol best practices honestly), but looks like you are instead updating the feed uri location? This should not be changed internally.

Oops! You're right, I misunderstood the bug report. It is in fact the field labeled "Feed Location" containing the feed's uri that's giving me grief. Overwriting the site location makes perfect sense now that I know exactly what was being discussed. :) As for my issue, is it reported in some other bug I missed that you'd know?

(In reply to jorge alves from comment #5) > As for my issue, is it reported in some other bug I missed that you'd know? Don't remember one offhand, maybe you want to try searching bugzilla, and if not found file it with steps to reproduce, possibly in a clean test profile.

let's stick this about editing site location, I think it's fine to override it with the feed value, but then we should not allow user to change it.

(In reply to Marco Bonardo [:mak] from comment #4) > (In reply to jorge alves from comment #3) > > Marco, I don't understand why it's overwritten, maybe a protocol > > requirement? > > The service tries to respect the choice of the feed author, by updating its > site uri (not sure if this is part of the protocol best practices honestly), > but looks like you are instead updating the feed uri location? This should > not be changed internally. This has been a problem for me with Delicious. They describe how to edit their feed to change the number of links returned, etc., but making this change manually doesn't last.

they should just provide a simple web page that does it for you and gives you a proper feed uri, requiring you to do manual changes is not really nice.

it's no more possible to edit the site uri of a livemark

I think you guys should reopen this, or provide some other solution to the following: I have a bunch (probably a couple of dozen) of RSS feeds that require HTTP basic authentication to read. The browser doesn't update those feeds unless I happen to have logged into the sites in question during the current session (which rarely happens, because the whole point of RSS is to avoid that). I am not prompted for passwords; the updates just fail. And I don't *want* to be prompted for passwords... there a ton of them, they're very low-value passwords, and I just want the browser to remember them across sessions and use them as needed. Since there's no general support for remembering HTTP basic passwords across sessions, I'd like to edit the feed URLs to embed the passwords there. But I can't. I'm willing to take responsibility for overriding the feed provider's choice of URL, but I don't get that option. So I'm basically hosed in terms of RSS for all those feeds. I'm guessing I'm not the only person in this position. And I'm also guessing there'd be a lot more authenticated RSS on the Web if it were easier... And about comment 9: that's the last thing I'd want. How is it nice to have to wander around a Web site looking for some weird form when I want to edit a URL?