The default bug view has changed. See this FAQ.

The ellipsis with text-overflow: ellipsis is sometimes one pixel too low

RESOLVED FIXED in mozilla7

Status

()

Core
Layout: Block and Inline
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: pcwalton, Assigned: mats)

Tracking

({pp, testcase})

unspecified
mozilla7
All
Mac OS X
pp, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [inbound])

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
Screenshots of Panorama attached. Sometimes the ellipsis is one pixel too low for me, depending on the block sizing, but not always.
(Reporter)

Comment 1

6 years ago
Created attachment 543533 [details]
Incorrect rendering for second row of tabs and below
(Reporter)

Comment 2

6 years ago
Created attachment 543534 [details]
Correct rendering for second row of tabs and below
(Assignee)

Comment 3

6 years ago
WFM in a local Linux64 mozilla-central build.  I can reproduce it on OSX
though.  A testcase would help debugging... do you know what kind of markup
are used for the text there?
(Reporter)

Comment 4

6 years ago
Here's the CSS in question (.tab-title):

http://hg.mozilla.org/mozilla-central/file/c97034c07fe6/browser/themes/pinstripe/browser/tabview/tabview.css#l133

and

http://hg.mozilla.org/mozilla-central/file/c97034c07fe6/browser/base/content/tabview/tabview.css#l73

And here's the markup:

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabview/tabitems.js#906
(Assignee)

Comment 5

6 years ago
Created attachment 543547 [details]
Testcase #1
(Assignee)

Comment 6

6 years ago
Testcase #1 looks fine on Linux on Windows XP.  Also when zooming up/down.

On OSX, the top three lines looks fine, on the next four the ellipsis is
too low, the bottom four looks good.
Keywords: testcase
(Assignee)

Comment 7

6 years ago
s/Linux on Windows/Linux and Windows/
(Reporter)

Comment 8

6 years ago
Confirmed on Mac.
(Reporter)

Updated

6 years ago
Hardware: x86 → All
(Assignee)

Comment 9

6 years ago
The problem is that nsTextFrame pixel-snaps the baseline.y before painting
the text, and we need to do the same when painting the marker text.
Should be an easy fix, just factoring out nsTextFrame::GetSnappedBaselineY
to nsLayoutUtils...
tracking-firefox7: --- → ?
Component: Layout: Text → Layout: Block and Inline
Keywords: pp
QA Contact: layout.fonts-and-text → layout.block-and-inline
Target Milestone: --- → mozilla7
(Assignee)

Updated

6 years ago
Assignee: nobody → matspal
(Assignee)

Comment 10

6 years ago
Created attachment 543626 [details] [diff] [review]
fix + reftest, rev. 1
Attachment #543626 - Flags: review?(roc)
Comment on attachment 543626 [details] [diff] [review]
fix + reftest, rev. 1

Review of attachment 543626 [details] [diff] [review]:
-----------------------------------------------------------------
Attachment #543626 - Flags: review?(roc) → review+
(Assignee)

Comment 12

6 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/cdff167e8074
Flags: in-testsuite+
Whiteboard: [inbound]
http://hg.mozilla.org/mozilla-central/rev/cdff167e8074
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
tracking-firefox7: ? → ---
You need to log in before you can comment on or make changes to this bug.