Closed
Bug 126610
Opened 23 years ago
Closed 21 years ago
block level element stops styles of <code> (also <samp>,<var>,<kbd>) [Quirk]
Categories
(Core :: DOM: HTML Parser, defect, P5)
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: pete, Assigned: harishd)
References
()
Details
(Keywords: compat, qawanted, testcase)
Attachments
(1 file)
275 bytes,
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+)
Gecko/20020219
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 2•23 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
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
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•23 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.
I still see this bug, I'm loading these pages a *lot* and see it only occasionally
Comment 7•22 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•22 years ago
|
||
No reaction --> worksforme. Reporter, you can still reopen the bug if you still
have the problem.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
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:
http://www.thegoldenear.connectfree.co.uk/gg/toolbox/win32/the-software.htm
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
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 10•22 years ago
|
||
WFM with the latest build: 2002-10-08-08-trunk on WIN2K. Reporter please feel
free to reopen this bug. Marking WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 11•22 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•22 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 :(
Reporter | ||
Comment 13•22 years ago
|
||
using 1.2b I saw this problem today with the footer of this page:
http://www.thegoldenear.connectfree.co.uk/gg/toolbox/win32/the-software.htm
(same footer as that previously described, just a different document)
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 14•22 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:
<http://validator.w3.org/check?uri=http%3A%2F%2Fwww.thegoldenear.connectfree.co.uk%2Fgg%2Ftoolbox%2Fwin32%2Fthe-software.htm&charset=%28detect+automatically%29&doctype=Inline>
This WorksForMe Win2K 20021108
If you can create a reduced test case that makes the bug happen every time, feel
free to try again.
-M
Reporter | ||
Comment 15•22 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
time
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•22 years ago
|
||
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.
Updated•22 years ago
|
Keywords: testcase
Summary: text font size occasionally displayed wrong → block level element stops styles of <code> (also <samp>,<var>,<kbd>) [Quirk]
Comment 17•22 years ago
|
||
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
Comment 18•22 years ago
|
||
Forgot to reassign.
Assignee: attinasi → harishd
QA Contact: amar → dsirnapalli
![]() |
||
Comment 19•22 years ago
|
||
Confirming to get this off the radar; QA and harish should get together and
decide whether to fix this.
![]() |
||
Comment 20•21 years ago
|
||
Harish and parser QA are no more. Choess, Ian, you are our last best hope!
What should we do here? ;)
Comment 21•21 years ago
|
||
Recipe ferrum! For semantic elements like this, I don't see any need to extend
quirks handling. Ian?
Comment 22•21 years ago
|
||
I agree. No more quirks. Especially not in the ridiculously fragile parser code.
![]() |
||
Comment 23•21 years ago
|
||
Done.
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•