Closed Bug 546007 Opened 16 years ago Closed 9 years ago

Underline is shifted upwards breaking the underline when both bold and italics is used to format a word.

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
2.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: miaturpel, Unassigned, NeedInfo)

References

(
URL
)

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) In a sentence that is both bold and underlined, the underline shifts upwards breaking the underline if a word is also italicized. Reproducible: Always Expected Results: Expected results are to view a continuous underline whether or not a word is italicized. I am an end user. I am viewing my website I hired someone else to create. I don't use themes or anything else.
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a2pre) Gecko/20100212 Minefield/3.7a2pre Seems like an old regression.
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
This worksforme on Mac, but it'll depend on the exact font metrics of the exact fonts that are installed, because the web page in question is in quirks mode and in quirks mode the underline position for each run of text style is based on the metrics of the font used for that text. If the specific font you're using has a different underline position for the italic face vs the upright one, you'll see this effect in quirks mode. The right fix to avoid this problem is to use standards mode on the web page... Ria, are you sure this is a regression at all? The behavior here shouldn't have changed in the last close to 10 years now.
Yes, it works fine with Firefox 1.5, but Firefox 2.0 and later show the problem. The regression range is fairly late however: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2008-02-15+01%3A00&maxdate=2008-02-16+00%3A00
Ria, thanks! The relevant thing in that range is the fix for bug 402524, which changed the way the OS-provided font metrics are converted into data we can actually use (including fixups for bogus OS-provided metrics, when we can detect them). It might be that the OS-provided metrics for the italic and non-italic font here are slightly different in a way that became visible as a result of that fix... Masayuki Nakano, can you take a look at the site in question, maybe?
Blocks: 402524
Status: UNCONFIRMED → NEW
Component: General → Graphics
Ever confirmed: true
QA Contact: general → thebes
I'm not sure whether this is an actual bug or not. The site specified Arial for the elements. We don't specify it's a bad font in default settings. So, the executed adjustments are: > 1239 aMetrics->underlineOffset = PR_MIN(aMetrics->underlineOffset, -1.0); > 1271 // If underline positioned is too far from the text, descent position is preferred so that underline > 1272 // will stay within the boundary. > 1273 else if (aMetrics->underlineSize - aMetrics->underlineOffset > aMetrics->maxDescent) { > 1274 if (aMetrics->underlineSize > aMetrics->maxDescent) > 1275 aMetrics->underlineSize = PR_MAX(aMetrics->maxDescent, 1.0); > 1276 // The max underlineOffset is 1px (the min underlineSize is 1px, and min maxDescent is 0px.) > 1277 aMetrics->underlineOffset = aMetrics->underlineSize - aMetrics->maxDescent; > 1278 } Probably the second block affects to this case. Looks like the italic style descent is shorter than non-italic style's. See the following testcase and select all text, then, you can see the selection rect height difference. > data:text/html,<html lang="en-US"><span style="font-family: Arial; font-weight: bold; font-size: 16px">xyz<i>xyz</i>xyz</span></html>
And note that if the web site doesn't use Quirks mode, the underline isn't broken by each style's metrics difference.
See bug 396809 for why we need the adjustment.
The underline difference will be fixed by bug 403524. If you think the metrics adjustment is a bug, this should stay. Otherwise, this should be marked as dup of the bug.
Hi, The link you provided is no longer available, can you please provide another one so I can test this on my end? Also, is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E). Thanks.
Flags: needinfo?(miaturpel)
Version: Trunk → 2.0 Branch
Marking this as Resolved: Incomplete due to the lack of response from the reporter. If anyone can still reproduce it on latest versions, feel free to reopen the issue and provide more information.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.