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)

x86
Windows 2000
defect

Tracking

()

VERIFIED WONTFIX

People

(Reporter: pete, Assigned: harishd)

References

()

Details

(Keywords: compat, qawanted, testcase)

Attachments

(1 file)

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)
Changing QA contact
QA Contact: petersen → amar
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
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
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.
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 → ---
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 ago22 years ago
Resolution: --- → WORKSFORME
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
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 :(
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 → ---
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
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">
Attached file testcase
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.
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.
Status: UNCONFIRMED → NEW
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.
Done.
Status: NEW → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: