352059 - <pre> tag uses variable-width font due to residual style

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect, P5)

Description

[Steve Shockley]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060908 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060908 Minefield/3.0a1

View the example page, scroll to the bottom to see the CAPTCHA "image", it's in a PRE block to preserve formatting.  On Minefield, extra spaces are removed so it's unreadable.  It looks okay in View Source, and looks okay in IE7 and FF 1.5.0.6.

Reproducible: Always

Steps to Reproduce:
View example page with Minefield, look at CAPTCHA "image".
Actual Results:  
Pre-formatted text is garbled.

Expected Results:  
Un-garbled preformatted text.

Comment 1

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060910 Minefield/3.0a1

Works for me.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Attachment: screenshot

Yeah, I see it too. Looks like a cairo thing as I can't reproduce it in non-cairo trunk.

Comment 3

[Adam Guthrie]

A minimized testcase here would be nice.

Comment 4

[Steve Shockley]

Attachment: Minimal test case

Here's a minimal test case for this bug.  Note that the bug goes away if I remove the font tag or close (or remove) the i tag.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

taking this.

I think that the cause is a invalid font-face specify in the HTML document. Now, we don't checking whether the font-face is a valid font family in the system. We should do it in bug 352174.

Comment 6

[Justin Kerk]

Fixed by the patch for bug 352174 (also changed summary to reflect what was actually going on).

Comment 7

[Marek Stępień [:marcoos, inactive]]

Is this really fixed?

I still see <pre> rendered with a proportional font, using Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9a1) Gecko/2006112404 Minefield/3.0a1

Comment 8

[Steve Shockley]

Test case renders properly for me, using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061125 Minefield/3.0a1 ID:2006112504 [cairo].

Comment 9

[Adam Guthrie]

Marek, please file another bug and attach a testcase. This originally worked on Linux, but I think Masayuki has broken it in one of his recent patches (probably bug 352174).

Comment 10

[Marek Stępień [:marcoos, inactive]]

OK, filed bug 362141.

Comment 11

[Steve Shockley]

This appears to have regressed in Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007080505 Minefield/3.0a8pre.  Both the original site and the test case render in a non-fixed-width typeface for me now.

Comment 12

[Martijn Wargers (dead)]

This regressed again between 2007-07-23 and 2007-07-25:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-23+04&maxdate=2007-07-25+09&cvsroot=%2Fcvsroot
Regression of bug 383960, apparently the backout of cairo wasn't complete then.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Are you sure this has anything to do with the cairo landing?  Cairo's not involved in any way in our font selection.

Comment 14

[Martijn Wargers (dead)]

Sorry, you're right, I blamed the wrong bug, I can see this bug also in the 2007-04-24 trunk build:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-23+04&maxdate=2007-07-24+09&cvsroot=%2Fcvsroot
Regression from bug 383979?

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So if this is a bug at all, it's an HTML parser bug.  The HTML parser is creating a document tree structure where the font tag is repeated inside the pre element.  Bug 383979 (or maybe bug 216456?) fixed some style system bugs.  If there's a <font face="helvetica"> inside a <pre>, we should make it Helvetica.

Comment 16

[Blake Kaplan (:mrbkap) (inactive)]

I wonder if we shouldn't bother opening residual style tags inside of <pre>, it seems to cause more confusion than good.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could you just drop the face attribute of font tags?

Comment 18

[Johnny Stenback (:jst)]

Blake, not sure how important this is, feel free to prioritize as you see fit.

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This isn't really a regression

Comment 20

[Mike Schroepfer]

(In reply to comment #19)
> This isn't really a regression
> 

If not should we drop from blocking list?

Comment 21

[Jesse Ruderman]

Sicking, what do you mean by "this isn't really a regression"?  Firefox 2 keeps the text preformatted and trunk doesn't, so it looks like a regression to me.

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah. It is in some ways a regression. Basically it's a case of two bugs previously canceling each other out, and now we fixed one of them.

So adding regression keyword.

Comment 24

[Daniel Hartmeier]

Just a warning, the undeadly site now removed all face attributes from font tags.

If anyone sees further mistakes in its HTML code that can be fixed to make the captcha render in fixed-pitched font for all Mozilla versions, please let me know (by email is fine, if not related to this bug report).

Thank you.

Comment 25

[Johnny Stenback (:jst)]

I don't think we want to touch this kind of stuff in a dot release. We should look at this for the next release.

Comment 26

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

I believe this is fixed by bug 487949.