- open bookmarks - find a long url that needs to be truncated because it's too wide for the column expected: - should be middle truncated, eg http://www.cnn.com/blah.../blah/foo.html actual: - start/end truncated, eg .../blah/blah/... this is basically useless. i think this is a bug in cropping in titled buttons, assigning to evaughan.
makes bookmarks kinda hard to use. nsbeta3
nsbeta3-/future, need to make the column wider til beta5 (aka 6.0.1)
you understand the column will almost never be wide enough and typically one cannot literally make head nor tail of the url? I understand it's crunch time, but I'm giving it one more try.
i've fixed bookmarks to just crop right (grr), so making this bug more generic.
Netscape Nav Triage Team: changing comp to XP Toolkit
Anybody wanna comment if this is going to be fixed before the _next_ millenium?
nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)
cc'ing the usual suspect.
How do I change bookmarks back to crop in the center to replicate this bug?
OK, I see this now. Shouldn't be that hard to fix. Pink, give this one to me if you want and I'll take care of it sometime next week.
I got to this a little earlier than I thought. I couldn't understand what was going on in the original code, so I rewrote it. I changed the crop in bookmarks.xul to be center and it works as I would it expect it to.
ask and ye shall receive.
Hey, that was easy. Now how about someone looking this over for an r=?
this doesn't account at all for the width of the ellipsis. won't the resulting string spill over |aWidth| by |ellipsisWidth|?
Actually, no. Previously this was subtracted twice. I found that it's already subtracted near the top of the function. http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsTextBoxFrame.cpp#3 76
ok then. r=pink
I moved the milestone to 0.9.1 last night, but that was probably too late. Moving to 0.9.2, although we can still get this into 0.9.1 if I get an sr=. I've already emailed Hyatt, so I'll fire something off to email@example.com.
I'll have to redo this now that bidi's in.
cc: ftang and mkaply to check out the bidi code. It's a copy-and-paste from what was there already.
indentation is inconsistent 2v.4 spaces + if (totalWidth > aWidth) + // greater than the allowable width break; + else else after break is like else after return. kill the else.
Don't know what happened with the indentation - I'll fix that and the "else" tonight.
I remember now. For the spacing, I was trying to maintain a consistent look with the existing code.
New patch coming up. I kept the indent at four spaces to be consistent with the rest of the file, and removed the "else"s after the "break"s.
pink or timeless, can you give an r= on my new patch with the bidi code? The bidi code hasn't changed at all, and that's the only change from the original patch that had r=pink.
r=timeless. things to consider: using nsLiteralString for ELLIPSIS (could be done now) talking to arik about making ELLIPSIS localizable... (could be done shortly) perhaps string iterators instead of integers (future)
timeless, I couldn't get nsLiteralString to compile, so let's add that to the "could be done shortly" bucket. Blake, care to sr?
firstname.lastname@example.org for bidi
We have to get this in for bug 85173. What's the error trying to use nsLiteralString? sr=blake
I couldn't get nsLiteralString, now apparently nsDependentString, to compile straight away. I think my tree's pretty up-to-date, but I get: 'nsDependentString' : no appropriate default constructor available I'm probably not understanding what timeless is asking for. We're not hurting anything with how it is now, I don't think. Since it's blocking bug 85173, I'm for checking this in, fixing up the bookmarks pane xul, and worrying about nsDependentString later (but soon, of course).
pushing out. 0.9.2 is done. (querying for this string will get you the list of the 0.9.2 bugs I moved to 0.9.3)
There's an r=, an sr=, and I don't have cvs access. Can someone check this in?
Fix checked in.
Filed bug 90840: "Bookmarks should use crop=middle" to address the original intent of this bug.
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]