Closed Bug 1017335 Opened 6 years ago Closed 6 years ago
No spacing between the bullet and text in a list-item
STR 1. load data:text/html,<ul><li>x ACTUAL RESULTS No spacing between the bullet and the "x" EXPECTED RESULTS Some spacing between the bullet and the "x" ADDITIONAL INFORMATION This is a regression in the last day or so. The bug occurs in a local mozilla-inbound build on Linux with a fresh profile. It does NOT occur in Nightly 2014-05-28.
It's a regression of bug 1013160 which has not been merged into the trunk. Should I fix it in that bug or this bug?
OK. After bug 1013160, numbers have a space appended as suffix instead of padding, however bullets are rendered in a different path which do not awared of the suffix. So what should the spacing depends on? Should we hardcoded some value for it? Or measure the width of space and add it to the padding? Or reintroduce some magic on padding?
Actually, now that bug 1013160 is backed out, it could go in either bug.
Jonathan, what's your opinion about comment 4?
Something like this might be good enough. (I guess it should assign mPadding.left for RTL though)
(In reply to Mats Palmgren (:mats) from comment #7) > Created attachment 8430468 [details] [diff] [review] > wip > > Something like this might be good enough. (I guess it should assign > mPadding.left for RTL though) That seems good, thanks. Would you like to fix it? Or let me fix it in bug 1013160?
OS: Linux → All
Hardware: x86_64 → All
You fixing it in bug 1013160 sounds fine to me :-)
Yes, I guess simply adding fm->SpaceWidth() is fine. It means the spacing will be dependent on the font being used, but that's also the case for numbers now, so whatever... We should also make sure to add a reftest for this (both LTR and RTL) - unit testing should have caught this earlier.
(In reply to Jonathan Kew (:jfkthame) from comment #10) > Yes, I guess simply adding fm->SpaceWidth() is fine. It means the spacing > will be dependent on the font being used, but that's also the case for > numbers now, so whatever... > > We should also make sure to add a reftest for this (both LTR and RTL) - unit > testing should have caught this earlier. I don't have idea how to build a reftest for the spacing between this kind of bullets and text.
(In reply to Xidorn Quan from comment #11) > I don't have idea how to build a reftest for the spacing between this kind > of bullets and text. Hmm, yes... I thought perhaps we could compare this with a "fake" version generated using text spans, etc., but it's a bit tricky because the exact placement of the bullet is different here. Presumably that's because it is positioned based on bounding boxes rather than as a piece of text.
Maybe something like this would be OK. It seems to work well for me locally; I've pushed it to try, to see if it survives across platforms: https://tbpl.mozilla.org/?tree=Try&rev=bb3e96298d11.
Comment on attachment 8430753 [details] [diff] [review] reftest for spacing between bullet and list item in <ul>. Well, tryserver says that's too fragile in various cases. I'll see if we can do something more robust.
Here's a version that should be much less fragile, with room for platform variations between fonts and with a couple of pixels' worth of padding on the background in case of antialiasing that extends beyond the bullet's nominal bounds. Looks to be coming up green on try: https://tbpl.mozilla.org/?tree=Try&rev=7b8ede1103f3, though not all results are in yet.
Attachment #8430884 - Flags: review?(matspal)
Attachment #8430753 - Attachment is obsolete: true
Attachment #8430884 - Flags: review?(matspal) → review+
Reftest: https://hg.mozilla.org/integration/mozilla-inbound/rev/b39cbf840af9 (The actual problem was fixed by updating the patch in bug 1013160.)
Assignee: nobody → jfkthame
Target Milestone: --- → mozilla32
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.