Closed Bug 239477 Opened 20 years ago Closed 20 years ago

strange space apears after a table using font tag inside an align=right cell

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: el_rulero, Assigned: hsaito54)

References

Details

(Keywords: testcase)

Attachments

(4 files)

the page shouldn't be widder than the window but it is
629 bytes, text/html
Details
really minimal testcase
225 bytes, text/html
Details
testcase using <b> tag
230 bytes, text/html
Details
patch
719 bytes, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040402 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040402 Firefox/0.8.0+

a gap appears between the right side of the window and a table meant to be the
size of the window when a font tag is used inside a cell aligned to the right in
the last column of the table (see test case attachment)

Reproducible: Always
Steps to Reproduce:
1.load the test case page attached

Actual Results:  
the page becomes wider than the window because the empty space added at the
right of the table

Expected Results:  
the table shold fit perfectly in the window
confirming: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040402

you don't need to use a <font> tag, it also works with <b>, or invalid tags like
<zz>, <fon>, <fantastic>. >ou don´t need a closing tag. You can use multiple
tags. Closing tags don´t work.
Minimal testcase needs one tag, one char, one space:

<tr><td align="right"><myTag>M </td></tr> is showing the bug, 
<tr><td align="right"></myTag>M </td></tr> is ok.
Status: UNCONFIRMED → NEW
Ever confirmed: true
changing the <x> tag to </x> kills the scrollbar, or changing the table border
to 3 or more.

<html><head><title>Bug 239477</title></head>
  <body marginwidth="0">
    <table border="1" cellpadding="0" cellspacing="0" width="100%">
      <tbody><tr><td align="right"><x>M </td></tr></tbody></table>
  </body></html>
This is probably a duplicate or at least dependency of a bug bz fixed by had to
back out a few months ago due to an editor regression.
Attached file testcase using <b> tag — 
previous testcase used a single, invalid <x> tag, 
this one uses a valid <b></b> pair:

<tbody><tr><td align="right"><b>M </b></td></tr></tbody></table>

Letter M can be any letter, I prefer M.
One or more spaces between the letter M and the </b> tag generate a horizontal
scrollbar, and the spaces between letter M and </td> tag are not shown.

<b>M </b></td> generates scrollbar, <b>M </b> </td> also, <b>M</b> </td> not.
That was bug 132561.  Marking dependency, but I'm not sure it's really related
here....
Depends on: 132561
btw, this doesn't happen with Firebird 0.7:
Mozilla/5.0 (Windows; U; Windows NT 5.0; es-AR; rv:1.5) Gecko/20031007 Firebird/0.7

the problem was introduced lately, at most with rv:1.6
*** Bug 239888 has been marked as a duplicate of this bug. ***
Assignee: nobody → saito
Keywords: testcase
Attached patch patch — — Splinter Review 

    
    

    
  
Subtracting from the combined area's width is wrong unless the combined area is
for a leaf frame.  Is that guaranteed to be the case here?  If so, comment; if
not, the patch is wrong.

    
    

    
  
The second piece you patch is for a leaf, but the first isn't.  However,
RelativePositionFrames is called after TrimTrailingWhiteSpace, so you're
probably OK.  Then again, this would all be easier if RelativePositionFrames
built up the combined area from scratch.

This seems reasonable, but I'd like roc's opinion.

    
    

    
  
Actually, though, I think this could break the case of trimming whitespace from
a relatively positioned inline acting as an absolute container, where the
absolutely positioned elements overflow the right edge of the inline.

    
    

    
  
> where the absolutely positioned elements overflow the right edge of the inline.

Yeah.

This whole area of code is horrible. I can't say for sure whether this patch is
correct or not.

Maybe Hideo could try modifying RelativePositionFrames to recalculate the
overflow area from scratch. That would simplify things a lot. Watch out for the
overflow area on relatively positioned spans, though; you'll need to distinguish
between the overflow due to absolutely positioned children and the overflow due
to overflowing inline children.

    
    

    
  
I dont see a scrollbar in attachment 45394 [details] with winxp seamonkey trunk 2004083008
(aka wfm)

    
    

    
  
*** Bug 249183 has been marked as a duplicate of this bug. ***

    
    

    
  
The testcases all WFM in 1.8a5.
Status: NEW → RESOLVED
Closed: 20 years ago
No longer depends on: 132561
Resolution: --- → WORKSFORME

    
    

    
  
It seems that this bug is fixed by a patch of Bug 252771.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: