Closed Bug 440112 Opened 15 years ago Closed 15 years ago

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


(Core :: Widget: Gtk, defect)

Not set





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



(Keywords: fixed1.9.0.2, fixed1.9.1)


(5 files)

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" "">
<body style="background-color: orange">
 <div id="wrapper" style="overflow:hidden;background-color: green;top: 100px; left: 100px; height: 150px; width: 200px">
     <textarea id="formElement" style="width: 100px;margin-left: 150px"> </textarea>
     <input type="text" style="width: 100px;margin-left: 150px"></input>

Reproducible: Always

Steps to Reproduce:
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 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
(In reply to comment #3)
> So 2.12.
> What about the build source?  Ubuntu, or

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 build?
(In reply to comment #5)
> OK.  Can you possibly check whether you also see it with a build?
Unfortunately, not better :-(.
Fetched the official build from, 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?
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 PatchSplinter Review
Assignee: nobody → ventnor.bugzilla
Attachment #326230 - Flags: superreview?(roc)
Attachment #326230 - Flags: review?(roc)
Comment on attachment 326230 [details] [diff] [review]

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 ReftestSplinter Review
Keywords: checkin-needed
Checked in
Closed: 15 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
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]

Approved for 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.
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.