(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #324945 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=324945 Imported into Bugzilla on 02/03/99 13:03) One of the changes to 4.5 is to support URLs longer than 255 characters in the Location field. If you bookmark a page that has a URL >255 characters (such as generated from a BugSplat query) and then edit that bookmark, to change the title for example, the URL will be trunctaed to 255 charcters. URLs >255 characters dragged to a browser window are also truncated before the load attempt occurs. Since 4.06 and earlier didn't support URLs >255 characters at all and the feature was added for 4.5 it really should be fixed before release.

Simon already fixed the case with dragging URLs >255 characters into a browser window (now allows up to 1024 characters). The truncation on edit is more serious but would require significant resource & code changes since the current design assumes the text field won't exceed 255 characters. Since it is not a simple fix and it is not technically a regression changing the TFV to 5.0 to get off the 4.5 radar.

Reassigning to saari for investigation of whether or not the bookmark changes in 5.0 have eliminated the truncation on editing problems.

Changing component to browser (not sure if this is still relevant, however).

Not an XPToolkit problem, reassigning to don@netscape.com

qa assigned set to claudius@netscape.com

Changed platform to All, Component to Apprunner, and priority to P3. We need to make sure this works correctly on all platforms, not just the Mac OS.

Changed component to XPApps and milestone target to M5.

Changed milestone target to M6.

Radha ...

Now that we use nsString to store and access urls in webshell we don't have such restrictions. cc'ing slamm, so that he can comment on bookmark editor window case.

In 4.x, I remember we placed a limit on bookmark length because the bookmark file code could not read super long urls (even though it wrote them just fine). People would unknowingly bookmark a page that had a super long title. They would quit the app and the next time they ran 4.x would crash on startup. We patched the problem by only allowing the code to write bookmarks out to the file that it could read. I forget what restriction we had, but it was in the 2,000 to 4,000 character range. Waterson used that code for mozilla, so I would guess that the restriction still applies. If a bookmark was too long, we would simple truncate the title. I do not know of any other restrictions that the Bookmarks Management window would have.

I copied the code in spirit, not line-by-line. The APIs and bookamrks.html parser all using nsStrings now, so there shouldn't be any limitation on the length of the bookmark's title or URL. That said, there could be a bugs in BookmarkParser::Parse() (see xpfe/components/bookmarks/src/nsBookmarksService.cpp, line ~350). Radha: if you want to reassign this bug to me (or RJC) that's fine.

giving rjc the love

Steve, what's the REAL bug that's being described?? 5.0 should handle bookmark URLs of *any* length.

I just editing a URL which was 550 characters in length and everything worked just dandy.

old bug, wfm on 2000051208