Closed Bug 440112 Opened 16 years ago Closed 16 years ago

Form elements are not hidden behind overlapping parent with overflow:hidden

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: markus.joschko, Assigned: ventnor.bugzilla)

References

Details

(Keywords: fixed1.9.0.2, fixed1.9.1)

Attachments

(5 files)

screenshot of test case
72.64 KB, image/png
Details
test case based on comment 0
529 bytes, text/html
Details
Patch
624 bytes, patch
roc
: review+
roc
: superreview+
samuel.sidler+old
: approval1.9.0.2+
Details | Diff | Splinter Review
Reftest
1.75 KB, patch
Details | Diff | Splinter Review
Sort reftest.list correctly by bug number
405 bytes, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0

Form elements should respect the overflow:hidden setting of their enclosing container. That means they should be hidden if they are bigger then the container. That is currently not the case in the linux version of ff3. The windows version is rendering that correctly. Please see the html code below. The form elements must not overlap the orange area, but they do in the linux version:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<body style="background-color: orange">
 <div id="wrapper" style="overflow:hidden;background-color: green;top: 100px; left: 100px; height: 150px; width: 200px">
    <form>
     <textarea id="formElement" style="width: 100px;margin-left: 150px"> </textarea>
     <input type="text" style="width: 100px;margin-left: 150px"></input>
     </form>
 </div>
</body>
</html>

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Component: General → Layout: Form Controls
Product: Firefox → Core
QA Contact: general → layout.form-controls
Markus, I can't seem to reproduce this.  What exact GTK version are you using?  What GTK theme?  Are you using a Mozilla.org build, or a distribution-provided one?
Hi Boris, that are good news. At least the bug is not so widespread then ;-)
I use kubuntu 8.04 with all updates installed. Is there an easy way to find out the exact version of gtk? gtk-lib has the version 2.12.9-3ubuntu4.
So 2.12.

What about the build source?  Ubuntu, or mozilla.org?
(In reply to comment #3)
> So 2.12.
> 
> What about the build source?  Ubuntu, or mozilla.org?

I see that issue on Ubuntu 8.04 with the FX rc 20080610 build (Ubuntu source)
(Ubuntu running in a Virtual machine)


OK.  Can you possibly check whether you also see it with a mozilla.org build?
(In reply to comment #5)
> OK.  Can you possibly check whether you also see it with a mozilla.org build?
Unfortunately, not better :-(.
Fetched the official build from Getfirefox.com, installed (and checked it was the downloaded one - yes - the Ubuntu provided one doesn't have any 'check for updates').

I'll attach screen shot and test case next.

Running in a Virtual machine with VirtualBox on top of OS X 10.5.3 - don't think it matters.


Hmm.  Come to think of it, the build I was testing might have been the latest I can run (so February, sometime).  So this might have just broken since then...

If so, that's a really nasty regression (and we should _definitely_) have a reftest for this.

Confirming and nominating to make sure it's at least on the radar.

My other Linux machine is in a box somewhere now, so I won't be able to usefully test this for about two weeks.  roc, could you maybe take a look, or get someone to?
Status: UNCONFIRMED → NEW
Component: Layout: Form Controls → Widget: Gtk
Ever confirmed: true
Flags: blocking1.9.1?
Flags: blocking1.9.0.1?
QA Contact: layout.form-controls → gtk
Sounds like there's an OPERATOR_CLEAR happening in an inconvenient place during native widget painting. I don't have much time to look at this right now, though.
Keep in mind that I haven't looked at this code for at least a month (and that's actually the code I'm looking at)

In gtk2drawing.c, in moz_gtk_entry_paint, I see the code


    /* Draw the default window background */
    gdk_draw_rectangle(drawable, style->base_gc[bg_state], TRUE,
                       rect->x, rect->y, rect->width, rect->height);

    /* Get the position of the inner window, see _gtk_entry_get_borders */
    x = XTHICKNESS(style);
    y = YTHICKNESS(style);

    if (!interior_focus) {
        x += focus_width;
        y += focus_width;
    }

    /* Simulate an expose of the inner window */
    gtk_paint_flat_box(style, drawable, bg_state, GTK_SHADOW_NONE,
                       cliprect, widget, "entry_bg",  rect->x + x,
                       rect->y + y, rect->width - 2*x, rect->height - 2*y);

Could that first statement be the issue?  Seems to me we are drawing a rectangle the size of our full entry, instead of only drawing it the size of cliprect
Yes, that is the cause.

Removing it seems to not have any negative side effects, why was it there in the first place?
Seems to be caused by bug 415494 as a fix for some themes quirks. It'd probably be best to just change the dimensions we paint the rectangle with to cliprect
Attached patch Patch — — Splinter Review 
Assignee: nobody → ventnor.bugzilla
Status: NEW → ASSIGNED

        Attachment #326230 -
        Flags: superreview?(roc)

        Attachment #326230 -
        Flags: review?(roc)

    
    

    
  
Comment on attachment 326230 [details] [diff] [review]
Patch

Please add a reftest for this.

        Attachment #326230 -
        Flags: superreview?(roc)

        Attachment #326230 -
        Flags: superreview+

        Attachment #326230 -
        Flags: review?(roc)

        Attachment #326230 -
        Flags: review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Reftest
        — 
          — Splinter Review
      

    


  

    
  
Keywords: checkin-needed

    
    

    
  
Checked in
f23a68123d0a
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED

    
  

        Attachment #326230 -
        Flags: approval1.9.0.1?

    
    

    
  
(In reply to comment #17)
> Checked in
> f23a68123d0a

This test is inserted at wrong position.
Please see
http://hg.mozilla.org/mozilla-central/index.cgi/diff/f23a68123d0a/layout/reftests/bugs/reftest.list

    
    

    
  


  
Please check this in.
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-

        Attachment #326230 -
        Flags: approval1.9.0.1? → approval1.9.0.2?

    
    

    
  
Comment on attachment 326230 [details] [diff] [review]
Patch

Approved for 1.9.0.2. Please land in CVS. a=ss

Also be sure to land the reftest in CVS as well.

        Attachment #326230 -
        Flags: approval1.9.0.2? → approval1.9.0.2+

    
  
Keywords: checkin-needed
Whiteboard: checkin needed to 1.9.0 branch

    
    

    
  
Checked into 1.9.0 branch with reftest.
Keywords: checkin-needed → fixed1.9.0.2
Whiteboard: checkin needed to 1.9.0 branch
Blocks: 435269
Flags: blocking1.9.1? → blocking1.9.1+

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: