Closed Bug 559733 Opened 10 years ago Closed 9 years ago

Bookmark title (name) is not parsed correctly (hence not showed and not saved) if it contains </a> in its URL

Categories

(SeaMonkey :: Bookmarks & History, defect, minor)

x86
Windows Server 2003
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: vshalimhr, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4

Bookmark title (name) is not parsed correctly if it contains the string "</a>" in its URL. And since it's not parsed correctly after the browser is restarted, it's not displayed in Bookmarks Manager GUI and not saved in the bookmarks.html file.


Reproducible: Always

Steps to Reproduce:
1. Create a bookmark with the "</a>" string in the "Location" field (URL), e.g. "javascript:'</a>';" without quotes.
2. Restart SeaMonkey (so that bookmarks.html file gets saved on browser exit and reparsed when browser starts).
3. Open Bookmarks Manager and see that bookmark has no title (neither in the Bookmarks Manager's tree, nor in the "Name" field in the "Bookmark Properties" dialog).
4. Close SeaMonkey.
5. Open bookmarks.html in a text editor and see that the bookmark has no title there - it's saved as <a href="javascript:'</a>';" ...></a>, i.e. the <a> tag has no child text node with bookmark's title.
Actual Results:  
Bookmark's URL is saved in the improper form (as is, not escaped): "javascript:'</a>';".

Expected Results:  
Bookmark's URL is saved in a properly escaped form: "javascript:'%3C/a%3E';".

This bug has the same nature as the infamous "</script>" issue of HTML parsers, the same workaround (you have to split the "</a>" string in two parts, e.g. "<" and "/a>"), and I think its root cause is improperly escaped bookmark's URL. Bookmarks Manager (or whatever thing is responsible for that) already escapes double quotes (it replaces them with %22), so why not to escape other symbols?
See bug 362552 for the corresponding Firefox bug.  This will most likely be fixed by bug 498596.
Depends on: SMPlacesBMarks
This has been fixed by bug 498596.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.