Bug 75422 - [testcase] <span><p></span> results in unclosed span
Summary: [testcase] <span><p></span> results in unclosed span
Status: RESOLVED UNMAINTAINED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml parsing (show other bugs)
Version: 3.2
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-17 09:58 UTC by Richard Bos
Modified: 2012-06-18 14:04 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
tar providing 4 test files (2.02 KB, application/x-tbz)
2005-01-07 11:29 UTC, Richard Bos
Details
File that shows the problem with a unfinished <p> tag (3.35 KB, text/html)
2005-01-10 20:38 UTC, Richard Bos
Details
This time the right archive showing the incorrect print behaviour (1.98 KB, application/x-tbz)
2005-01-10 20:57 UTC, Richard Bos
Details
The simplified testcase (55 bytes, text/html)
2005-01-10 21:39 UTC, Maksim Orlovich
Details
More informative test (123 bytes, text/html)
2007-10-12 18:55 UTC, Allan Sandfeld
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Bos 2004-02-17 09:58:52 UTC
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 }
-}
Comment 1 Richard Bos 2004-02-17 10:22:48 UTC
For completion: an example of the code that is used with the noprint class:

<SPAN class=noprint>[More]</SPAN>
Comment 2 Maksim Orlovich 2005-01-06 00:10:05 UTC
That's what the webpage's CSS specifies.
Comment 3 Richard Bos 2005-01-06 20:29:25 UTC
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.
Comment 4 Maksim Orlovich 2005-01-06 20:58:38 UTC
I stand corrected. Do you have a sample page/testcase where something inappropriate happens?
Comment 5 Richard Bos 2005-01-07 11:26:30 UTC
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>
Comment 6 Richard Bos 2005-01-07 11:29:20 UTC
Created attachment 8973 [details]
tar providing 4 test files
Comment 7 Maksim Orlovich 2005-01-07 17:37:53 UTC
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
Comment 8 Richard Bos 2005-01-10 12:31:50 UTC
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.
Comment 9 Richard Bos 2005-01-10 20:38:52 UTC
Created attachment 9028 [details]
File that shows the problem with a unfinished <p> tag
Comment 10 Maksim Orlovich 2005-01-10 20:44:19 UTC
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..
Comment 11 Richard Bos 2005-01-10 20:57:18 UTC
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 ;)
Comment 12 Maksim Orlovich 2005-01-10 21:37:00 UTC
Confirmed, thanks for your patience and help.
further simplified testcase:
<SPAN style="display:none">
<p>
Text
</SPAN>
More text


Comment 13 Maksim Orlovich 2005-01-10 21:39:27 UTC
Created attachment 9032 [details]
The simplified testcase
Comment 14 Allan Sandfeld 2005-03-30 14:20:47 UTC
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;
Comment 15 Allan Sandfeld 2007-10-12 18:55:39 UTC
Created attachment 21810 [details]
More informative test
Comment 16 Nic Gould 2008-04-06 17:15:06 UTC
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.
Comment 17 Zayed Al-Saidi 2008-10-18 05:55:50 UTC
same as comment # 16 with kde 4.1.2
Comment 18 Allan Sandfeld 2008-10-22 15:19:10 UTC
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.
Comment 19 Myriam Schweingruber 2012-06-18 14:04:20 UTC
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.