Text 1px too low in this case

RESOLVED INVALID

Status

()

Core
Layout
P2
normal
RESOLVED INVALID
11 years ago
10 years ago

People

(Reporter: stevee, Assigned: dholbert)

Tracking

({regression, testcase})

Trunk
x86
All
regression, testcase
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Reporter)

Description

11 years ago
Created attachment 289674 [details]
testcase from reporter. shows 'Some text here' 1px too low

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007111705 Minefield/3.0b2pre ID:2007111705

Filed on behalf of Chainfire from IRC.

1. New profile, start firefox
2. Load testcase
3. Observe 'Some text here' box at top

Expected:
- Text line should be 1px higher to match other browsers

Actual:
= Text line is 1px too low
(Reporter)

Comment 1

11 years ago
Rendering the same as other browsers:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007030411 Minefield/3.0a3pre

Rendering 1px too low:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007030415 Minefield/3.0a3pre

Checkins to module PhoenixTinderbox between 2007-03-04 10:00 and 2007-03-04 16:00 : 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-04+10&maxdate=2007-03-04+16&cvsroot=%2Fcvsroot

Due to bug 370588?
Blocks: 370588

Updated

11 years ago
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
(In reply to comment #2)
> Windows only?
> 

Nope -- I see this on Linux.
OS: Windows 2000 → All
Created attachment 291751 [details]
testcase 2

So, for a 2px increase in line-height, the text shifts down by 1px. (because it's centered in the line, I think.)  This is true on both FF2 and FF3.

The difference, though, is *which* 1px increase out of the 2 will trigger the text to shift down by 1px.

Looking at this testcase, here's the difference between FF2 and FF3 (on Linux)
 FF3 on Linux: text moves when line-height increases from ODD to EVEN
 FF2 on Linux: text moves when line-height increases from EVEN to ODD

In more detail:
 - For odd line-heights, FF2 and FF3 agree
 - When we step up 1px, to an even line-height, FF3 shifts the text down by 1px, and FF2 doesn't, so they disagree.  
 - When we step up another 1px, to an odd line-height, FF2 shifts the text down by 1px, and FF3 doesn't.  So FF2 "catches up" to FF3, and they agree again.
(In reply to comment #6)
> Looking at this testcase, here's the difference between FF2 and FF3 (on Linux)
>  FF3 on Linux: text moves when line-height increases from ODD to EVEN
>  FF2 on Linux: text moves when line-height increases from EVEN to ODD

Windows is the same as Linux for the FF2/FF3 difference here.
 FF3 on Windows: text moves when line-height increases from ODD to EVEN
 FF2 on Windows: text moves when line-height increases from EVEN to ODD

But interestingly, Mac is the exact reverse
 FF3 on Mac: text moves when line-height increases from EVEN to ODD
 FF2 on Mac: text moves when line-height increases from ODD to EVEN


Here are results on other browsers, FWIW:
 IE7 on Windows:      ODD to EVEN
 Safari on Mac:       ODD to EVEN
 Konqueror on Linux:  EVEN to ODD
 Opera on Linux:      EVEN to ODD
I actually get consistent results between FF2 and FF3 on all of Mac, Windows and Linux. Has this been fixed recently?

In any case, we've never guaranteed pixel-consistent baseline positioning and I don't think we should start guaranteeing that, so I'm pretty tempted to mark this not blocking.
Whiteboard: [needs feedback]

Comment 9

10 years ago
Problem still exists on Minefield 2008-01-07 (just tested).

As for 'never guaranteed pixel-consistent baseline positioning' and making it non-blocking; That's all very well for you to say, but some of us have to make pages that look nice crossbrowser too, this move would make that impossible. An odd line-height is the only way to make fonts look good and consistent across the 4 major browsers on the 3 major platforms (yes, even with Safari's font rendering system). 

Ok, that's not entirely true, you need to add a CC-based fix for IE6 (but hey, what piece of good-looking CSS doesn't require that?). It wouldn't be a problem if Firefox supported CC's as well, but this has been deemed bad practise and to some point I agree with that; however, in the real world there is sometimes no escaping it.

Graphically intensive and crossbrowser nice looking pages are already a PITA to make now (yes, sometimes that is what is called for), why not make your job easier and our job harder? Besides, who ever cared about consistency? Stuff like this makes people use Flash, is that what we want?
I'm also seeing this bug with the first testcase, with current trunk windows build.
Whiteboard: [needs feedback]
> Stuff like this makes people use Flash, is that what we want?

Of course not, but that doesn't mean we should turn HTML+CSS into a pixel-accurate page description language. SVG is the Web-standards solution for that.

I'll see what I can do, but I have to be able to reproduce it first.
(In reply to comment #9)
> Problem still exists on Minefield 2008-01-07 (just tested).

Same here -- to be more specific, I still see buggy behavior on both the original testcase and on testcase 2 (as described in Comment 7) using a Linux trunk build from 2008-01-07.
Daniel, do you want to take this?
(In reply to comment #13)
> Daniel, do you want to take this?
> 

Sure.
--> Stealing.
Assignee: roc → dholbert
Priority: P3 → P2
Created attachment 302206 [details]
spreadsheet: compare FF3 vs FF2 on testcase 3 across font-sizes

Here's a CSV spreadsheet of FF3 and FF2's behavior on testcase 3, with various "font-size" values.  "Yes" means that the text moves on the first click; "No" means that the text doesn't move until the second click.

Notice that FF3 and FF2 have the same behavior for all font-sizes *except* for 2px-16px.  (16px is the default height, at least on my Linux machine)

The builds I tested were:
FF2 = Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12
FF3 = Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020708 Minefield/3.0b4pre
I didn't notice it before, but the differences in rendering for font-size: 2px to 16px described in comment 16 are actually due to the *inital conditions* -- for those font sizes, FF2 starts the text out 1px higher than FF3 does.

I'm pretty sure that's happening due to rounding errors because we have fewer app-units per pixel in FF2.

On my system, FF2 uses 15 app-units per pixel, whereas FF3 uses 60.

In the starting conditions of testcase 3, the text is at y-position = 1/2px.
In FF2, this is 7 app-units, which in actuality is *less* than 1/2px.  In FF3, this is 30 app-units, which is *exactly* 1/2px.

For small fonts (i.e. those less than 16px tall -- see comment #16) the difference between a exactly-half-a-pixel and slightly-less-than-half-a-pixel could make a difference in the positioning of the text.

Gonna do a bit more testing to verify this, but I'm pretty sure that's what's going on.  (and as a result this is probably not a bug.)
Attachment #289674 - Attachment description: testcase from reproter. shows 'Some text here' 1px too low → testcase from reporter. shows 'Some text here' 1px too low
(In reply to comment #17)
> Gonna do a bit more testing to verify this, but I'm pretty sure that's what's
> going on.  (and as a result this is probably not a bug.)

Yup -- in all the situations I'm seeing where FF2 and FF3 differ in this respect, the text is at a Y-position that's 7appUnits off of 1px -- e.g. it's at 7, or 22, or 37, or 52, etc.  In these situations, FF2 places the text 1px higher than FF3, due to the loss of precision in rounding 1/2 px = 15/2 = 7.

This is true of the original testcase, testcases 2, and for testcase3 with a variety of font-sizes that I tested.  (For the fontsizes where FF2 == FF3, the text's y-position was always an even pixel value -- 15, 30, 45, etc)


So -- I'm chalking this bug up to a rounding error in FF2 that's been corrected by the higher precision in FF3's app-units.  Resolving as invalid, since it's not a bug in FF3.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.