Closed Bug 422251 Opened 17 years ago Closed 17 years ago

<pre>-tag is not shown in fixed-font

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 352059

People

(Reporter: bugzilla, Unassigned)

Details

(Keywords: regression, testcase)

Attachments

(2 files)

Testcase
(deleted), text/html
Details
Slightly modified testcase
(deleted), text/html
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) Gecko/2008030318 Firefox/3.0b4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) Gecko/2008030318 Firefox/3.0b4 With Firefox beta 3 and beta 4 on Linux and Windows (maybe others and previous versions) I've noticed whatever is put inside a <pre>- or <code>-tag is not shown in a fixed-font. I've also reported this before through the 'report broken web page'-system with Beta 3, but Beta 4 still has the same problem. Reproducible: Always Steps to Reproduce: As an example of what happends: 1. goto the http://undeadly.org/-site 2. reply to an article or comment. 3. There is an ASCII-art-"captia" at the bottom, it's not readible, because it's not in a fixedwidth-font. 4. Take a look at it with view-source, there the ASCII-art is fully visible. Actual Results: text inside <pre>- or <code>-tags are not shown in a fixed-width font. Expected Results: rendering in a fixed-width font. A simple HTML(4?)-document (<html><body><pre>test</pre></body></html>) shows the same problem. I've not tried this with a XHTML-page. There might be other tags which should probably render in a fixed width font.
Leen: I see this on that one site, but not on any other sites. Is that true for you, too? Looking in DOMI, I see a child font tag of the pre (it's up higher in the source, it gets duplicated due to the special font tag parsing rules): <font face=helvetica" color="#336666" size="3"> Assuming the site hasn't changed, could it be that we're now matching this to the helvetica font, where we used to not match it to anything? A regression range would be very helpful here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Linux → All
Hardware: PC → All
Attached file Testcase (deleted) —
Flags: blocking1.9?
Keywords: testcase
Attached file Slightly modified testcase (deleted) —
Fixed the font-tag-attribute to actually have helvetica like the undeadly.org-page and not hevetica. Added extra situation with font-tag around pre-tag. Added extra situations with good font-tags.
Yes, you are right, it's just on this site. I thought it was more widespread, but it really is just this page. And you also were spot on with the bad attribute in the HTML. This definitely seems to play a big part in the differences I see in the different versions of Firefox. As far as I can see, the difference is between Firefox 2 and Firefox 3 Beta (I've tested on Linux and Windows with Firefox 2 and Firefox 3 Beta 3 and Firefox Beta 4). So to put it more clear, Firefox 2 shows the page with a fixed-width font and the Firefox 3 Beta's with a non-fixed-width font. I've looked at your test-case, it's really interresting the way this shows how the different Firefox-versions display it differently. If I test your test-case as it is now, it will show in Firefox 2: 2 fixed width pieces of text. In Firefox 3 Beta (4) it will show only one of the texts in a fixed width font. But I've noticed the test-case isn't the same as the undeadly-page. In the undeadly-page the font-tag is around the pre-tag, in the test-case it's the other way around. Also the attribute in the test-case has hevetica, not helvetica. So I uploaded a new test-case. Now I don't know how important this really is, because we are talking about faulty HTML anyway, because the attribute isn't right. When I do know is, it's not the same as Firefox 2. Which could be good or bad and possible intended. The more I look at it, I think maybe the Firefox 3 way is the better way. Even though it did 'break' the already broken page. Firefox 3 seems to better 'understand' what was intended. PS For completeness Firefox 2 on Linux is actually Iceweasel of Debian stable.
Component: Layout: Fonts and Text → HTML: Parser
QA Contact: layout.fonts-and-text → parser
Whiteboard: DUPEME
This looks like a dupe of bug 352059.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Flags: blocking1.9?
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: