User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100821 Minefield/4.0b5pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100821 Minefield/4.0b5pre When hardware accelerated rendering is enabled on Windows, block list items are 1px higher than they should be. Reproducible: Always Steps to Reproduce: 1. Download a recent nightly on Windows 7 with DirectX 10 hardware 2. Go to http://www.alistapart.com/ or any other website with block list navigation 3. Use Firebug to look at list item height, compare with height when directwrite rendering is disabled Actual Results: Block list items are 1px too high (e.g. 39px instead of 38px) Expected Results: List items should be the correct height. This causes problems on many sites (see attachment for example).
Created attachment 468321 [details] Example of block list items being 1px too high when hardware accelerated rendering is enabled
Which hardware accelerated pref are we talking about here? d2d or dwrite?
Component: DOM: CSS Object Model → Graphics
QA Contact: general → thebes
Theodore, can you turn off Direct2D temporarily - instructions here https://wiki.mozilla.org/Platform/GFX/Direct2DDemo - and let us know whether your problem remains? (Turning off D2D will keep DirectwWrite on, letting us know if this is a D2D issue or a font metrics issue.)
(In reply to comment #2) > Which hardware accelerated pref are we talking about here? d2d or dwrite? (In reply to comment #3) > Theodore, can you turn off Direct2D temporarily - instructions here > https://wiki.mozilla.org/Platform/GFX/Direct2DDemo - and let us know whether > your problem remains? (Turning off D2D will keep DirectwWrite on, letting us > know if this is a D2D issue or a font metrics issue.) Setting mozilla.widget.render-mode to 0 makes the problem go away. In Firefox 4.0 beta 4, you won't see this issue unless you open about:config, filter for the word 'render', and set gfx.font_rendering.directwrite.enabled to true, and mozilla.widget.render-mode to 6.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This may explain why the app button is larger than it should be.
I think this was resolved somewhere along the line.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.