Closed Bug 337760 Opened 19 years ago Closed 17 years ago

Live Bookmarks do not recognize Atom feeds with namespace prefixes

Categories

(Firefox :: Bookmarks & History, defect)

2.0 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ahouseholder, Unassigned)

References

Details

Attachments

(4 files)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 I had an atom feed which specified <atom:feed xmlns:atom="http://www.w3.org/2005/Atom">... and so forth throughout (all atom elements were prefixed with atom:, and feedvalidator.org confirmed the feed was valid. Firefox reported "Live Bookmark failed to load" when I'd create a live bookmark for this feed. I changed the header to <feed xmlns="http://www.w3.org/2005/Atom"> , removing the namespace prefix, and the Live Bookmarks load fine. For what it's worth NetNewsWire and Bloglines were both okay with the prefixed feed. The namespace prefix is perfectly legal XML. This should have worked. As it is, the workaround is to ensure that http://www.w3.org/2005/Atom is the default namespace for any atom feeds you want to use as Live Bookmarks, but this doesn't seem like its the correct behavior. Reproducible: Always Steps to Reproduce: 1. Start with any valid Atom feed. 2. Change the <feed> tag to be <atom:feed xmlns:atom="http://www.w3.org/2005/Atom"> 3. Replace each subsequent tag with the atom: namespace prefix (e.g., <title> becomes <atom:title>, etc.) 4. Try to load this new file with the namespace prefix as a Live Bookmark. Actual Results: Live Bookmark failed to load. Expected Results: The feed should load as Live Bookmarks.
Version: unspecified → 1.5.0.x Branch
This is an example feed that works.
This feed does not work. The only difference between the one that works and the one that doesn't is the xml namespace & the presence of the atom: ns prefix in broken.xml's tags.
*** Bug 359958 has been marked as a duplicate of this bug. ***
This bug also affects Firefox 2 and is not limited to the Mac OS X version.
True. However, what really matters is that it does not affect trunk builds with places-bookmarks enabled, which use a different parser, so despite the fact that you'll have a very hard time finding a working build right now, it's already fixed for what we'll next ship, and fixing it in 2.0.x branch releases is almost certainly not going to happen.
OS: Mac OS X → All
Hardware: Macintosh → All
Version: 1.5.0.x Branch → 2.0 Branch
I have checked the latest nightly build (found at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk) and this bug is not fixed. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070218 Minefield/3.0a3pre
Did you not see the parts where I said "with places-bookmarks enabled" and "you'll have a very hard time finding a working build right now", or just ignore them? In any case, I wasn't asking you to find http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/places/ and verify what I already know is true about which parser it uses for livemarks, just explaining that this bug exists in nsBookmarksFeedHandler.cpp, which we don't intend to ship for 3.0, and for which fixes to make it namespace aware would not be branch-safe, and does not exist in nsLivemarkService.js, so while this bug is valid as long as nsBookmarksFeedHandler.cpp is around, the only activity you're likely to see here is an eventual marking invalid once it's no longer around.
Places bookmarks have recently landed on trunk. The namespace issue no longer exists. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070520 Minefield/3.0a5pre
i still can reproduce testcase in Comment #2 on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070917 Minefield/3.0a7pre
Both testcase 2 and 3 work in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070904 Minefield/3.0a7pre
Well, an eventual marking it invalid or an eventual marking it worksforme, one or the other.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: