RESOLVED CONFIGURATION CHANGED 5287
A paragraph with "display: block" is hidden until you resize fonts (using Cmd Plus & Cmd Minus or menus) 
https://bugs.webkit.org/show_bug.cgi?id=5287
Summary A paragraph with "display: block" is hidden until you resize fonts (using Cmd...
Rimas Kudelis
Reported 2005-10-06 23:22:37 PDT
At the bottom of http://rq.online.lt/, there's a paragraph (id="navigation"). For it, a CSS rule "display: block" is specified, however, the paragraph is hidden somewhy unless you press Cmd+ or Cmd- or change font size through the menus. Then, if you go to page 2, the paragraph gets hidden again untill you cycle font size again. This bug has been reported and fixed in KDE a while ago. Link: https://bugs.kde.org/show_bug.cgi? id=89249.
Attachments
KDE patch (9.09 KB, patch)
2006-01-13 14:58 PST, Alexey Proskuryakov 		no flags
DetailsFormatted DiffDiff
Test case (78 bytes, text/html)
2008-02-20 10:51 PST, mitz 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2006-01-13 14:58:21 PST
Created attachment 5647 [details] KDE patch KDE fix updated for current WebKit (their svn revision is 371719). It fixes the site, but 1) increases the size of NodeImpl, which doesn't sound good; 2) breaks several WebKit regression tests (could easily be caused by my mistake of some kind, of course).
mitz
Comment 2 2006-01-14 01:44:15 PST
While I haven't tested it yet, I don't see how this patch addresses things like children being inserted/ removed dynamically (which is currently broken too).
Dave Hyatt
Comment 3 2006-01-14 01:50:29 PST
Yeah I've basically rejected this patch once before already. I don't want to increase the size of elements just to handle rarely-used CSS selectors that WinIE doesn't even support yet. There are ways to code this that can avoid increasing the DOM element size.
Dave Hyatt
Comment 4 2006-01-14 01:52:50 PST
As for breaking regression tests, it's probably fixing CSS2.1 tests that we checked in broken.
Alexey Proskuryakov
Comment 5 2006-01-14 05:06:31 PST
There were several failures in dom and editing; plus a hang in fast/dom. I didn't look any further. Yes, dynamic adding/removing isn't addressed, see <https://bugs.kde.org/show_bug.cgi?id=95266#c7>. BTW, this patch is based on what was actually checked in, not what was attached to that bug.
mitz
Comment 6 2006-05-03 02:25:32 PDT
*** Bug 8679 has been marked as a duplicate of this bug. ***
mitz
Comment 7 2008-02-20 09:43:31 PST
I was expecting this to be fixed by the recent work on CSS3 selectors, but I can still reproduce the bug.
mitz
Comment 8 2008-02-20 10:49:14 PST
The problem is now specific to style rules that result in not creating a renderer. Element::finishParsingChildren() calls checkStyleRules(this, renderStyle(), true) but renderStyle() is 0.
mitz
Comment 9 2008-02-20 10:51:54 PST
Created attachment 19232 [details] Test case
Alexey Proskuryakov
Comment 10 2010-06-11 17:17:29 PDT
This is still a problem with r60936.
Alexander Pavlov (apavlov)
Comment 11 2011-11-23 05:11:16 PST
The test case works for me on r101054 - displays "Did not fail". Should the bug be closed now?
Ahmad Saleem
Comment 12 2022-05-29 06:29:16 PDT
Appreciate if this bug can be closed because as mentioned by Alexander - this is working as intended across all browsers with attached test case showing "Did not fail." across Safari 15.4, Chrome Canary 104 and Firefox Nightly 102.
Alexey Proskuryakov
Comment 13 2022-05-31 09:43:43 PDT
Thank you for checking, done!
Note You need to log in before you can comment on or make changes to this bug.