Version: (using KDE KDE 3.2.0) Installed from: SuSE RPMs OS: Linux Using konqueror as usual just browsing and things like that. I decide to print the page. Select the print button and the printer widget pops up. Select 'print', at that moment a warning/error window pops up stating that the application/x-zerosize is not supported. When the html source is altered it is possible to have the document printed from konqueror. The html code to be removed is: -@media print { - SPAN.noprint { display: none } -}
For completion: an example of the code that is used with the noprint class: <SPAN class=noprint>[More]</SPAN>
That's what the webpage's CSS specifies.
Maksim, that is not what the CSS specifies. The CSS specifies that the text in the <SPAN class=noprint> tag is not printed, like links that can not be selected from paper. Please note that any other browser I use can deal with. Konqueror is the only one that does not print the page at all.
I stand corrected. Do you have a sample page/testcase where something inappropriate happens?
Maksim, I have 4 test files attached to the bugreport, which show the problem quite nicely. Using the following table will make the situation clear: Test File Text Result Comment (noprint-?.html) Top Bottom ----------------------------------------------------------------------- 1 ............. no no no print (but that seems okay) 2 ............. no yes no print (bug) 3 ............. yes no print (okay) 4 ............. yes yes print (but text-1 only, text-2 is is not printed) (tip: n use 'print preview' to check) I did not test a html page that has, something like: <p>text-1p> <span class=noprint> text-2 </span> <p>text-3p> <span class=noprint> text-4 </span> <p>text-5p>
Created attachment 8973 [details] tar providing 4 test files
I don't see anything wrong there, using 3.3.2-post. In particular, note that you're not closing </SPAN> before the text-2 tags, so that's not suppose to print
Maksim, I found the problem now. It is due to a unfinished <p> tag in the <span class="noprint"> section. If I remove the <p> or add a </p> to complete the tag, it all works as designed. Now is this a bug in khtml?? Maybe, on the other hand it is also a bug on the webpage, and I'all ask the owner to change it. Hopefully that will be done. Added noprint-5.html to show the bug.
Created attachment 9028 [details] File that shows the problem with a unfinished <p> tag
Are you sure you attached the right file? That attachment works fine for me (post 3.3.2 3.3.x-branch, though, so could be fixed). At any rate, what you described sounds like a parser bug..
Created attachment 9030 [details] This time the right archive showing the incorrect print behaviour noprint-5.html okay noprint-5.1.html not good *diff = diff file ;)
Confirmed, thanks for your patience and help. further simplified testcase: <SPAN style="display:none"> <p> Text </SPAN> More text
Created attachment 9032 [details] The simplified testcase
Not sure if it is the right way to fix it, but the following addition to the residual style patch from #20976 fixes this bug as well: diff -u -3 -p -w -r1.357 htmlparser.cpp --- html/htmlparser.cpp 30 Mar 2005 11:53:51 -0000 1.357 +++ html/htmlparser.cpp 30 Mar 2005 12:19:52 -0000 @@ -1155,6 +1155,7 @@ bool KHTMLParser::isResidualStyleTag(int case ID_VAR: case ID_DEL: case ID_INS: + case ID_SPAN: return true; default: return false;
Created attachment 21810 [details] More informative test
Tested in 4.0.3 using latest testcase from comment #15. Problem still exists in this version, both text lines appear green appears to be caused by the lack of a /p tag. In firefox only the first line appears green as intended.
same as comment # 16 with kde 4.1.2
I would like to note that my old patch in this bug, is not a correct solution. If to be "fixed" we need to move to firefox-like parsing where all elements have the same level, and we instead us ad-hoc parsing-contexts. As is we use levels and inline-level elements like SPAN can not auto-close block-level elements like P in a leveled parsing. In a context-based parsing all elements have the same level within their context, and you just implement a truck-load of quirky contexts. So it is also a choice of sane and simple (and coincidental IE-compatible) parsing, or insane and quirky Firefox parsing. I believe we are doing the right thing, but we might need to reexamine it based on HTML5 primarily codifying Firefox parsing behaviour.
Message from the Bugsquad and Konqueror teams: This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore. If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report. Thank you for your understanding.