Open Bug 144517 Opened 21 years ago Updated 2 months ago

A frame is only created for the first of multiple table-captions, and only when at start (?) of table

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect

Tracking

()

Project Flags:
Webcompat Priority P3

People

(Reporter: dogjam, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: css2, testcase)

Attachments

(5 files, 1 obsolete file)

Testcase
134 bytes, text/html
Details
a smaller testcase
75 bytes, text/html
Details
a smaller testcase
66 bytes, text/html
Details
the second solution
1.05 KB, patch
Details | Diff | Splinter Review
the first solution
787 bytes, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2)
Gecko/20020510
BuildID:    2002051006

In the page at http://www.nettally.com/joelhill/alkan/Index.html, neither text
nor links appear, only background image and color. Works fine on other browsers.

Reproducible: Always
Steps to Reproduce:
Open http://www.nettally.com/joelhill/alkan/Index.html.

Actual Results:  No text or links.

Expected Results:  Show text and links, as featured in the source page.
Looks like an unclosed <caption> tag at the beginning.
Confirm. I'd bet it's those unclosed <caption> elements. cc'ing harishd in case
this ought to be handled in the parser.
Assignee: attinasi → karnaze
Status: UNCONFIRMED → NEW
Component: Layout → HTMLTables
Ever confirmed: true
QA Contact: petersen → amar
Priority: -- → P4
agree.

If you add </caption> in the orignal html file,then the dsplay is correct.
If delete the second <caption> or add a </caption> after it,you will find the
display is correct.
change platform to all.
OS: Windows XP → All
Hardware: PC → All
Attached file Testcase — 

    
    

    
  
The problem of the testcase and url is that:
 it has two open caption tag, and content is between the second caption.

but html4 dtd said that table has only 0 or 1 caption, so the second caption
doesnot show.

One way to resolve it is that when parser meet the second open caption, omit it.



    
    

    
  
Although I agree with jerry on previous comments,
I think we can also resolve it in layout module 

so balance is necessary.

:)
OS: All → Windows XP
Hardware: All → PC

    
    

    
  

      
      
      
      

        Attached file
          
        a smaller testcase
        — 
      

    


  

    
    

    
  
Assign to leon, since karnaze is on vacation.

    
    

    
  

      
      
      
      

        Attached file
          
        a smaller testcase
        — 
      

    


  

    
    

    
  
assign to me
Assignee: karnaze → leon.zhang

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch 0.1  (obsolete)
        — 
          — Splinter Review
      

    


  
a simple method to reslove the bug.

to ensure robustness,need more modification :)

    
  
OS: Windows XP → All

    
    

    
  
Leon, you need to take care this case.
<caption>abc<caption>abc

so I think your patch may judge that whethere it has open caption before the
latter caption when handle the latter caption token.
not just only calculate parent and child.

change component to parser.
Component: HTMLTables → Parser

    
    

    
  


  

    
    

    
  
The source of the bug:
1)During parsing the html file,when meet the second <caption> of testcase:
<table><caption><caption></caption>,  mozilla will call CloseContainer and
create frame. So when process </caption>,mozilla will create frame again,
but during add the frame ,mozilla will check whether there exist a <caption>
frame for the tableframe:  if yes,then destory the latter one.

2)According the process above, the content between the second<caption> and
</caption> will be destroyed and cannot be displayed.also the content between
the two <caption> still can display correctly.

About previous patch:
becuase the parser works always in the unit of atoken(mapped to tag), and the
current tag (not in stack) can always compare  with his parent tag(stay in
stack), so the two <caption> tag can meet each other,and the one in stack is
parent and the current one is child,i.e. the patch is valueable.

BTW,even for testcase 
"<html><body><table><caption>ccc<b><caption>bbbb</caption></table></body></html>"
the previous two patchs can works.

    
    

    
  


  
based on the patch 0.1

    
    

    
  
This might solve the problem for this case, but it doesn't seem like it would
solve the problem in the general case of 'display: table-caption', or even for
XHTML.  Also, would it solve the problem if there's something separating the two
CAPTION elements?

It's not clear what the correct thing to do if we encounter multiple captions
for a table is.  One possibility is just to put the content outside the table,
although I'm not sure whether that's a good idea.

    
    

    
  
To follow up on dbaron's comments, in order to fix that stuff you'd need to
catch this case in nsCSSFrameConstructor and, instead of not constructing
anything, construct a frame of some other type (probably display: block).

Whether it is worth changing the fix is up to Evangelism or someone who knows
what usage is on the web.  People shouldn't be doing this crap anyway; XHTML
users better know the difference, and someone nesting style="display:
table-caption" is being ultra-silly too.

    
    

    
  
...but unlike multiple caption elements, multiple elements with 'display:
table-caption' are not invalid.

    
    

    
  
At this point my advice would be to wait a while and see if we get duplicates or
something. At this point we are quite reluctant to change the parser unless
there is big enough gain that offsets the risks of breaking something else.
Summary: No text on the page, while source page shows that there should be one → Multiple table caption elements cause stuff inside second caption to disappear

    
    

    
  
currently,the frame constructor has mechanism which can prevent creating two or
more cpations for a tableframe: 

nsCSSFrameConstructor::ContentAppended
.....
        nsCOMPtr<nsIAtom> childFrameType;
        tempItems.childList->GetFrameType(getter_AddRefs(childFrameType));
        if (nsLayoutAtoms::tableCaptionFrame == childFrameType.get()) {
          PRBool abortCaption = PR_FALSE;
          // check if a caption already exists in captionItems, and if so, abort
the caption
          if (captionItems.childList) {
            abortCaption = PR_TRUE;
          }
          else {
            // check for a caption already appended to the outer table
            nsIFrame* outerTable;
            parentFrame->GetParent(&outerTable);
            if (outerTable) { 
              nsIFrame* existingCaption = nsnull;
              outerTable->FirstChild(aPresContext, nsLayoutAtoms::captionList,
&existingCaption); 
              if (existingCaption) {
                abortCaption = PR_TRUE;
              }
            }
          }
          if (abortCaption) {
            tempItems.childList->Destroy(aPresContext);
          }
          else {
            captionItems.AddChild(tempItems.childList);
          }
......

Component: Parser → HTMLTables

    
    

    
  
I agree with heikki.
If there is no dup of this bug,
   we may change the component to Tech Evangelism, and ask the author to change
its html code.

    
    

    
  
We should prvide a more robust browser other than escape the current issue. 
That the main contents of a webpage cannot be displayed, is not a good feature
for mozilla.

    
    

    
  
Change component to parser.
If it is for robust, assign to parser.
Component: HTMLTables → Parser

    
    

    
  
No, if we are going to do some kind of real robustness we need to not throw away
the second caption frame, but instead do something with it.  That's not parser,
that's frame constructor (and that's tables).

    
  
Assignee: leon.zhang → nobody
URL: http://www.nettally.com/joelhill/alka...
Component: HTML: Parser → Layout: Tables
Keywords: testcase
Priority: P4 → --
QA Contact: amar → layout.tables
Hardware: x86 → All
Summary: Multiple table caption elements cause stuff inside second caption to disappear → A frame is only created for the first of multiple table-captions

    
    

    
  
This comment is per bug 477462 comment #20.

dbaron is wondering whether this bug is really valid. I do think so because of what CSS 2.1 says:

http://www.w3.org/TR/CSS21/tables.html#model
> (...) the table box  (...) contains (...) any caption boxes (in document
> order). The caption boxes are block-level boxes (...) and are rendered as
> normal blocks inside the anonymous box. Whether the caption boxes are placed
> before or after the table box is decided by the 'caption-side' property,
> as described below.

IE and Opera do render mutliple caption elements.
Flags: wanted1.9.2?

    
  
Keywords: css2
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2-

    
  
Blocks: css2.1-tests

    
  
Summary: A frame is only created for the first of multiple table-captions → A frame is only created for the first of multiple table-captions, and only when at start (?) of table

    
    

    
  
Tests in CSS 2.1 test suite with multiple captions:

http://test.csswg.org/suites/css2.1/latest/html4/table-caption-002.htm

http://test.csswg.org/suites/css2.1/latest/html4/table-header-group-003.htm [1]

http://test.csswg.org/suites/css2.1/latest/html4/table-footer-group-003.htm [1]

http://test.csswg.org/suites/css2.1/latest/html4/border-spacing-applies-to-015.htm

There may be other tests with multiple captions.

[1] The text chunk "either one or" in table-header-group-003 and table-footer-group-003 tests has been reported to be incorrect, wrong and should be removed.

    
    

    
  
From https://drafts.csswg.org/css-tables-3/#caption-side-property,

> Gecko has a bug when dealing with multiple captions.
> Testcase: http://codepen.io/FremyCompany/pen/WrJxwP
Blocks: 1654362
Webcompat Priority: --- → ?
Webcompat Priority: ? → P3

    
  
Severity: normal → S3

    
    

    
  
The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.

:dholbert, could you consider increasing the bug severity?


For more information, please visit auto_nag documentation.


Flags: needinfo?(dholbert)

    
    

    
  
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.


Flags: needinfo?(dholbert)
Duplicate of this bug: 1803981

    
    

    
  
I'm seeing this issue with Atlassian Confluence 7.3.5.


Some of the table captions aren't being rendered. I was unable to find the bit of info I was looking for on a wiki with firefox.



          You need to log in
          before you can comment on or make changes to this bug.