block level element stops styles of <code> (also <samp>,<var>,<kbd>) [Quirk]




17 years ago
15 years ago


(Reporter: petes-lists, Assigned: harishd)


({compat, qawanted, testcase})

Windows 2000
compat, qawanted, testcase

Firefox Tracking Flags

(Not tracked)




(1 attachment)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+)
BuildID:    2002021903

text in the footer of this page, below the horizontal line, is very occasionally
rendered in 10pt when it should be 8pt. reloading the page always renders the
text size correctly

(this has a resemblance to bug 125056 but seems different enough as this isn't
about text flow (allthough the links don't flow the same as IE, but maybe thats
a design issue, I haven't searched for comment on it yet; and it does flow
consistantly) and is an occasional bug rather than a persistant one.
you'll also notice bug 93717 taking place amongst the text in question)

Comment 1

17 years ago
Changing QA contact

QA Contact: petersen → amar

Comment 2

17 years ago
 Reporter there are lot of HTML errors in the given page. <table>, <html> etc 
tags were not closed. That might be causing the error.
Priority: -- → P5

Comment 3

17 years ago
oops. I see. but...recently the pages haven't been uploading to the ftp site
fully, just 95% or 98%, as it is as I write this and when you looked at it. in
this instance when I reload the page it doesn't alter the font size to what it
should be, but I believe in the past when I reported this bug the page (and
othes on the same site) had fully uploaded to the server and a page reload fixed
the rendering in the browser. I'll upload it again and make sure there is 100%
of the file there

Comment 4

17 years ago
I saw this bug again today; could it perhaps be related to the bug that causes
Mozillazine to not render correctly until the page is refreshed? as I am getting
that again with Mozillazine in the last couple of days for the first time in a
long while

Comment 5

17 years ago
page seems to work fine for me with trunk 2002062808 on win2k, and I haven't
seen any similar issues recently.

reporter: are you still seeing this bug? if not, then please resolve this as
worksforme. thanks.

Comment 6

17 years ago
I still see this bug, I'm loading these pages a *lot* and see it only occasionally

Comment 7

16 years ago
still WFM - win2k/1.1 final.

reporter: can you reproduce this bug with a recent build of mozilla (for
example, the 1.1 release)? if so, please comment again with details. if not,
please resolve this as WORKSFORME. thanks.

Comment 8

16 years ago
No reaction --> worksforme. Reporter, you can still reopen the bug if you still
have the problem.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 9

16 years ago
odd. I just experienced this bug after a long time not doing so, a couple of
seconds before your Bugzilla post about arrived in my email!

I had it on this page:

exactly as I first described, but with Mozilla 1.1. I only ever see it in my
pages on this site and in the footer
Resolution: WORKSFORME → ---

Comment 10

16 years ago
WFM with the latest build: 2002-10-08-08-trunk on WIN2K. Reporter please feel
free to reopen this bug. Marking WFM. 
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 11

16 years ago
but I *do* keep reopening this bug. see commment #8 and comment #9. admittedly
I'm not using a recent build at the moment. this is an intermittent bug, so when
you say "WFM", how many times have you visited the page? as I'd only see it once
every couple of weeks and I look at the pages every day

Comment 12

16 years ago
well next time you're using a recent build and this happens again, reopen it yet
again... :)

unless we can identify some way of reproducing and/or identifying the exact
cause of the bug, it's not really possible to fix it... intermittent issues are
annoying like that :(

Comment 13

16 years ago
using 1.2b I saw this problem today with the footer of this page:
(same footer as that previously described, just a different document)
Resolution: WORKSFORME → ---

Comment 14

16 years ago
Reporter --

Unfortunately, unless you can figure out what is more specifically causing the
problem, or give any more details as to what might be fixed, no engineer will be
able to figure out what's wrong from what's written so far. Intermittent bugs
are really hard to fix.

In addition, you will notice that all the pages you've cited don't validate as
valid HTML 4.01 Transitional. In particular, there are problems with some of
your <link> tags, I believe, which may be causing the problem.

See it here:

This WorksForMe Win2K 20021108

If you can create a reduced test case that makes the bug happen every time, feel
free to try again.


Comment 15

16 years ago
in my code I was using:
<code class="eight">
<hr width="100%">
and in Mozilla versions prior to 1.3 the text beyond the hr was most often
displayed in 8pt (as per my style sheet) but occasionally displayed in the
default font size

Mozilla 1.3, however, displays text beyond the hr in the default font size every

it appears the <hr width="100%"> in Mozilla 1.3 is cancelling the font size
statement. this might just be example of my not understanding enough HTML

I am now using the following, which displays the text in the correct font size:
<hr width="100%">
<code class="eight">

Comment 16

16 years ago
Created attachment 118187 [details]

I think this bug is INVALID

<code> is inline element and <hr>, which is block level, should close
it so <code> style no longer applies. This is the same for samp, var,
and kbd elements. This does not apply to <font> in Quirk mode.
Curiously, this also does not apply to <tt> in Quirk mode.


16 years ago
Keywords: testcase
Summary: text font size occasionally displayed wrong → block level element stops styles of <code> (also <samp>,<var>,<kbd>) [Quirk]
I'd also go with INVALID.

Basically the "problem" here is that the residual style fix-up code in the
parser only fixes bogus use of presentational inline elements but not the bogus
use of these logical inline elements.
Component: Layout → Parser
Forgot to reassign.
Assignee: attinasi → harishd
QA Contact: amar → dsirnapalli
Keywords: compat
Confirming to get this off the radar; QA and harish should get together and
decide whether to fix this.
Ever confirmed: true
Keywords: qawanted
Harish and parser QA are no more.  Choess, Ian, you are our last best hope!  
What should we do here?  ;)
Recipe ferrum! For semantic elements like this, I don't see any need to extend
quirks handling. Ian?
I agree. No more quirks. Especially not in the ridiculously fragile parser code.
Last Resolved: 16 years ago15 years ago
Resolution: --- → WONTFIX


15 years ago
You need to log in before you can comment on or make changes to this bug.